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Предисловие 


В результате взрывного развития Пиегпей, беспроводных видов связи и сетей со- 
размерно увеличилось число программистов и инженеров, занимающихся разра- 
боткой сетевых приложений. Программирование ТСР/ТР может показаться об- 
манчиво простым. Интерфейс прикладного программирования (АРТ) несложен. 
Даже новичок может взять шаблон клиента или сервера и создать на его основе 
работающее приложение. 

К сожалению, нередко после весьма продуктивного начала неофиты начинают 
понимать, что все не так очевидно, а созданная ими программа оказывается и мед- 
ленной, и нестабильной. В сетевом программировании есть множество «темных 
уголков» и трудно понимаемых деталей. Цель этой книги - ответить па возникаю- 
щие вопросы и помочь разобраться с тонкостями программирования ТСР/[Р. 

Прочитав данную книгу, вы научитесь преодолевать трудности сетевого про- 
граммирования. Здесь будут рассмотрены многие вопросы, на первый взгляд, лишь 
отдаленно связанные с теми знаниями, которыми должен обладать программист 
сетевых приложений. Но без понимания таких деталей не разобраться в том, как 
сетевые протоколы взаимодействуют с приложением. Ранее казавшееся загадоч- 
ным «поведение» приложения при ближайшем рассмотрении становится совер- 
шенно понятным, решение проблемы лежит на поверхности. 

Книга построена несколько необычно. Типичные проблемы представлены в виде 
серии советов. Разбираясь с конкретным вопросом, вы будете переходить к изуче- 
нию того или иного аспекта ГСР/ТР. К концу главы вы не только решите частную 
задачу, но и углубите понимание того, как работают и взаимодействуют с прило- 
жением протоколы ТСР/[Р. 

Разбивка книги на отдельные советы в какой-то мере лишает текст логической 
последовательности. Чтобы помочь вам сориентироваться, в главу 1 помещен пу- 
теводитель, описывающий расположение материала. Получить общее представле- 
ние об организации книги поможет также оглавление, в котором перечислены все 
советы. Поскольку каждый совет дан в повелительном наклонении, оглавление 
можно считать списком рецептов. 

С другой стороны, Такая организация материала позволяет использовать кни- 
гу в качестве справочника. Столкнувшись в повседневной работе с какой-либо 
проблемой, вы можете обратиться к соответствующему совету, чтобы вспомнить 
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ее решение. Многие темы затрагиваются в нескольких советах, иногда под раз- 
ным углом зрения. Такое повторение помогает усвоению сложных концепций, 
проясняя мотивы тех или иных решений. 


Аудитория 


Данная книга предназначена, главным образом, начинающим и программистам 
среднего уровня, но даже опытные специалисты найдут в ней много полезного для 
себя. Хотя и предполагается, что читатель знаком с сетями и основами АР] на базе 
сокетов, в главе 1 приводится обзор элементарных вызовов АРГи их использования 
для создания примитивного клиента и сервера. В совете 4 более детально рассмот- 
рены модели клиента и сервера, поэтому даже читатель с минимальной подготовкой 
сможет извлечь из представленного материала практическую пользу. 

Почти все примеры написаны на языке С, безусловно, необходимы базовые 
навыки программирования на этом языке для понимания приведенных в книге 
программ. В совете 31 представлены некоторые примеры на языке Рег|. Но, впро- 
чем, предварительное знание Рег| необязательно. Здесь встречаются и небольшие 
примеры на языках командных интерпретаторов (зЪе!), но и для их понимания 
знакомства с зБе-программированием не нужно. 

Материал для изучения подан по возможности максимально независимо от 
платформы. За немногими исключениями, приводимые в примерах программы 
должны компилироваться и работать на любой платформе ОМХ или \Лп32. Но 
программисты, которые используют системы, отличные от ОМХ и УЛп4до\з, тоже 
могут без особых трудностей применять примеры на своей платформе. 


Принятые в книге соглашения 


По ходу изложения приведены небольшие программы для иллюстрации раз- 
личных аспектов исследуемой проблемы. Здесь будут использоваться следующие 
соглашения: 


О текст, который набирает пользователь, печатается полужирным моноши- 
ринным шрифтом; 

О текст, который выводят системы, печатается обычным моноширинным 
шрифтом; 

О комментарии, не являющиеся частью ввода или вывода, печатаются кур- 
сивным моноширинным шрифтом. 


Пример из совета 9: 


Ьза: $ Есрки 1оса1ров* 9000 

Ве11о 

получено сообщение 1 печатается после пятисекундной задержки 
здесь сервер остановили 

Ве11оада1п 

Есрги: ошибка вызова геаа11пе: Соппес®1оп гезек Бу реек (54) 

Ьза: $ 


Оформление ПН ВИ И И ЕЕ 


Обратите внимание на приглашение командного интерпретатора, содержащее 
имя системы. Предыдущий пример исполнялся на машине с именем Ь34. 

В рамке дается описание вводимой в рассмотрение новой функции АР] - соб- 
ственной или системного вызова. Стандартные системные вызовы обводятся 
сплошной рамкой: 


#1пс]1ц@е <зуз/зоскее.в> /* ОМХ */ 
#1пс1аае <и1пзосКк2.Н> /* М1паоме * / 


106 соппес® { ЗОСКЕТ 5, сопзё зе кисё зоскаЯаахг *реег, 116 реег_1еп); 


Возвращаемое значение: 0 -— нормально, —1 (ОМХ) или не 0 (\Мп4о\м) — 
ошибка. 


Разработанные автором функции обведены пунктирной рамкой: 


АН авы" а л 


#1пс1аае "еёср.В" 
ЗОСКЕТ Е ср_вегуег ( спаг *НозЕ, сваг *рогё ); 


| Возвращаемое значение: сокет в режиме прослушивания (в случае ошибки За- 
‚вершает программу). 


а т еее] 


Примечание Таким образом отмечены попутные замечания и дополнитель- 
ный материал. При первом чтении подобный материал можно 
пропускать. 


Наконец, О ВТ. подчеркивается: 


Бер: / Ил гееБ$Ч.огв. 
Исходные тексты и список исправлений 


Исходные тексты всех встречающихся в книге примеров представлены на сай- 
те издательства «ДМК-Пресс» Вр: / ммм АтК.ги. Вы можете загрузить их на свой 
компьютер и поэкспериментировать. На этом сайте находятся каркасы программ 
и код библиотечных функций. 


Оформление 


Мне очень нравится оформление книг Ричарда Стивенса*. Приступая к работе 
над этой книгой, я попросил у Рича разрешения скопировать его стиль. Рич со 
свойственным ему великодушием не только не возражал, но даже посодействовал 
ЭТОЙ «краже», прислав мне макросы для форматера СВОЕЕ которыми он пользо- 
вался при наборе своих книг. 

Если вам понравится это издание, то благодарить следует Рича. В противном 
случае загляните в любую из его книг, чтобы понять, к чему я стремился. 


* Речь идет о трехтомном издании «ТСР\!Р Шиягае4» и двухтомном «ИМХ Меёмогк Ргоягат- 
пупа». — Прим. перев. 
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Благодарности 


Традиционно авторы книг благодарят свои семьи за поддержку во время ра- 
боты над книгой, и теперь я знаю, почему. Эта работа не была бы закончена, если 
бы не помощь моей жены Марии. И эти слова — лишь жалкая попытка воздать ей 
долж-ное за дополнительные хлопоты и одинокие вечера. 

Также ценнейшую поддержку оказали рецензенты. В ранних вариантах руко- 
писи они нашли многочисленные ошибки, как технические, так и типографские, 
разъяснили то, что я неправильно понимал или не знал, предложили свежий под- 
ход. Хочется выразить благодарность Крису Клиланду (СЬг! Сее!апа), Бобу Джил- 
лигену (Воь СИЙвап, ЕгееСае Согр.), Питеру Хэверлоку (Реег Науейоск, Моке] 
МеруотЁ$), С. Ли Генри ($. [ее Непгу, \УеБ Ри 1 5Ыпв, Гпс.), Мукешу Кэкеру 
(МикКезЬ КаскКег, Зип М1сгозу$етз, [пс.), Барри Марголину (Ваггу Магвойп, СТЕ 
Пицегпеуогтлв), Майку Оливеру (МЩе ОйПуег, Зип М1сгозуетаз, [пс.), Юри Рацу 
(От Ка2) и Ричу Стивенсу (ЕсВ З(еуеп$). 

Необходимо поблагодарить редактора Карен Геттман (Кагеп СеЙтап), ведуще- 
го редактора Мэри Гарт (Магу Наг(), координатора проекта Тиреллу Элбо (Туггей 
АТБаи8Ъ) и корректора Кэт Охала (Саё ОБа[а). Мне было приятно с ними рабо- 
тать, они очень помогли начинающему автору. 

Я приветствую любые замечания и предложения читателей. Пишите мне по 
электронному адресу, указанному ниже. 


Йон Снейдер 


Тампа, Флорида зпаае’@1х.песот.сот 
Декабрь, 1999 рр /ююшпекот.сот/ -[5падЕГ 


Глава 1. Введение 


Цель этой книги — помочь программистам разных уровней - от начального до 
среднего — повысить свою квалификацию. Для получения статуса мастера требу- 
ется практический опыт и накопление знаний в конкретной области. Конечно, 
опыт приходит только со временем и практикой, но данная книга существенно 
пополнит багаж ваших знаний. 

Сетевое программирование - это обширная область с большим выбором раз- 
личных технологий для желающих установить связь между несколькими машина- 
ми. Среди них такие простые, как последовательная линия связи, и такие сложные, 
как системная сетевая архитектура (ЗМА) компании ВМ. Но сегодня протоколы 
ТСР/ТР - наиболее перспективная технология построения сетей. Это обусловлено 
развитием Пицегпе и самого распространенного приложения - Всемирной паути- 
ны (УМогА УЛае У№еЬ). 


Примечание Вообще-то, \еЬ -— не приложение. Но это и не протокол, хотя 
в ней используются и приложения (Б-браузеры и серверы), 
и протоколы (например, НТТР). \Ь - это самое популярное сре- 
ди пользователей риетей применение сетевых технологий. 


Однако и до появления \еЬ ТСР/Р был распространенным методом созда- 
ния сетей. Это открытый стандарт, и на его основе можно объединять машины раз- 
ных производителей. К концу 90-х годов ТСР/ТР завоевал лидирующее положе- 
ние среди сетевых технологий, видимо, оно сохранится и в дальнейшем. По этой 
причине в книге рассматриваются ТСР/ТР и сети, в которых он работает. 

При желании совершенствоваться в сетевом программировании необходимо 
сначала овладеть некоторыми основами, чтобы в полной мере оценить, чем же вам 
предстоит заниматься. Рассмотрим несколько типичных проблем, с которыми стал- 
киваются начинающие. Многие из этих проблем - результат частичного или пол- 
ного непонимания некоторых аспектов протоколов ТСР/ТР итех АРГ, с помощью 
которых программа использует эти протоколы. Такие проблемы возникают в ре- 
альной жизни и порождают многочисленные вопросы в сетевых конференциях. 


Некоторые термины 


За немногими исключениями, весь материал этой книги, в том числе примеры 
программ, предложен для работы в системах ОМХ (32 и 64-разрядных) и систе- 
мах, использующих АРТ Мисгозой УМп4о\ (\Йп32 АРТ). Я не экспериментировал 
с 16-разрядными приложениями УЛодо\з. Но и для других платформ почти все 
остается применимым. 
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Желание сохранить переносимость привело к некоторым несообразностям 
в примерах программ. Так, программисты, работающие на платформе О МХ, неодоб- 
рительно отнесутся к тому, что для дескрипторов сокетов применяется тип 5ОСКЕТ 
вместо привычного 1п*. А программисты УЙп4о\’з заметят, что я ограничился толь- 
ко консольными приложениями. Все принятые соглашения описаны в совете 4. 

По той же причине я обычно избегаю системных вызовов геаЯ и иг1%е для 
сокетов, так как \Йп32 АР] их не поддерживает. Для чтения из сокета или записи 
в него применяются системные вызовы гесу, гесуЁком или гесутз9д для чтения 
и зепа, зепаёо или зепапза для записи. 

Одним из самых трудных был вопрос о том, следует ли включать в книгу мате- 
риал по протоколу ГРуб, который в скором времени должен заменить современ- 
ную версию протокола [Р ([Ру4). В конце концов, было решено не делать этого. 
Тому есть много причин, в том числе: 


О почти все изложенное в книге справедливо как для [РУ4, так и для [Руб; 

О различия, которые все-таки имеются, по большей части сосредоточены в тех 
частях АРТ, которые связаны с адресацией; 

О книга представляет собой квинтэссенцию опыта и знаний современных се- 
тевых программистов, а реального опыта работы с протоколом ГРуб еще не 
накоплено. 


Поэтому, если речь идет просто об ТР, то подразумевается 1Ру4. Там, где упо- 
минается об [Руб, об этом написано. 

И, наконец, я называю восемь бит информации байтом. В сетевом сообществе 
принято называть такую единицу октетом -— по историческим причинам. Когда-то 
размер байта зависел от платформы, и не было единого мнения о его точной длине. 
Чтобы избежать неоднозначности, в ранней литературе по сетям и был придуман 
термин октет. Но сегодня все согласны с тем, что длина байта равна восьми битам 
[КегуевВап апа Р\Ще 1999], так что употребление этого термина можно считать из- 
лишним педантизмом. 


Примечание Однако утверждения о том, что длина байта равна восьми битам, 
время от времени все же вызывают споры в конференциях Ибепе: 
«Охужэта нынешняя молодежь! Я в свое время работал на маши- 
не Баста-6, в которой байт был равен пяти с половиной битам. 
Так что не рассказывайте мне, что в байте всегда восемь бит». 


Путеводитель по книге 


Ниже будут рассмотрены основы АР] сокетов и архитектура клиент-сервер, 
свойственная приложениям, в которых используется ТСР/[Р, Это тот фундамент, 
на котором вы станете возводить здание своего мастерства. 

В главе 2 обсуждаются некоторые заблуждения по поводу ТСР/ГР и сетей во- 
обще. В частности, вы узнаете, в чем разница между протоколами, требующими 
логического соединения, и протоколами, не нуждающимися в нем. Здесь будет рас- 
сказано об [Р-адресации и подсетях (эта концепция часто вызывает недоумение), 
обесклассовой междоменной маршрутизации (С]аз$ез$ Пиегдотат Воципя — СТОЕ) 
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и преобразовании сетевых адресов (Меб\уогЕ А4@гезз Тгапз|айоп — МАТ). Вы уви- 
дите, что ТСР в действительности не гарантирует доставку данных. И нужно быть 
готовым к некорректным действиям как пользователя, так и программы на другом 
конце соединения. Кроме того, приложения будут по-разному работать в глобаль- 
ной (\/АМ) и локальной (ГАМ) сетях. 

Следует напомнить, что ТСР - это потоковый протокол, и разъяснить его зна- 
чение для программистов. Вы также узнаете, что ТСР автоматически не обнару- 
живает потерю связи, почему это хорошо и что делать в этой ситуации. 

Вам будет понятно, почему АР] сокетов всегда следует предпочитать АР] на ос- 
нове интерфейса транспортного уровня (Тгапзроге Гауег Пиегасе — Т) и транс- 
портному интерфейсу Х/Ореп (Х/Ореп Тгапзроге [т{ег[асе — ХТГ). Кроме того, 
я объясню, почему не стоит слишком уж серьезно воспринимать модель открыто- 
го взаимодействия систем (Ореп Зуз%етз [т{егсоппесНоп - ОЗГ). ТСР - очень эф- 
фективный протокол с отличной производительностью, так что обычно не нужно 
дублировать его функциональность с помощью протокола (ОР 

В главе 2 разработаны каркасы для нескольких видов приложений ТСР/ТР и на 
их основе построена библиотека часто используемых функций. Каркасы и библио- 
тека позволяют писать приложения, не заботясь о преобразовании адресов, управ- 
лении соединением и т.п. Если каркас готов, то вряд ли следует срезать себе путь, 
например, «зашив» в код адреса и номера портов или опустив проверку ошибок. 

Каркасы и библиотека используются в книге для построения тестов, неболь- 
ших примеров и автономных приложений. Часто требуется всего лишь добавить 
пару строк в один из каркасов, чтобы создать специализированную программу или 
тестовый пример. 

В главе 3 подробно рассмотрены некоторые вопросы, на первый взгляд кажу- 
щиеся тривиальными. Например, что делает операция записи в контексте ТСР. 
Вроде бы все очевидно: записывается в сокет п байт, а ТСР отсылает их на другой 
конец соединения. Но вы увидите, что иногда это происходит не так. В протоколе 
ТСР есть сложный свод правил, определяющих, можно ли посылать данные не- 
медленно и, если да, то сколько. Чтобы создавать устойчивые и эффективные про- 
граммы, необходимо усвоить эти правила и их влияние на приложения. 

То же относится к чтению данных и завершению соединения. Вы изучите эти 
операции и разберетесь, как нужно правильно завершать соединение, чтобы не 
потерять информацию. Здесь будет рассмотрена и операция установления соеди- 
нения соппеск: когда при ее выполнении возникает тайм-аут и как она использу- 
ется в протоколе (ОР 

Будет рассказано об имеющимся в системе ОМХ суперсервере 1пека, упро- 
щающим написание сетевых приложений. Вы научитесь пользоваться программой 
Есртих, которая избавляет от необходимости назначать серверам хорошо извест- 
ные порты. Узнаете, как работает Е сриих, и сможете создать собственную версию 
для систем, где это средство отсутствует. 

Кроме того, здесь подробно обсуждаются такие вопросы, как состояние Т1МЕ- 
УАП, алгоритм Нейгла, выбор размеров буферов и правильное применение оп- 
ции 50_ВЕОЗЕАОТВ. Вы поймете, как сделать свои приложения событийно-управляе- 
мыми и создать отдельный таймер для каждого события. Будут описаны некоторые 
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типичные ошибки, которые допускают даже опытные программисты, и приемы 
повышения производительности. 

Наконец, вы познакомитесь с некоторыми языками сценариев, используемы- 
ми при программировании сетей. С их помощью можно легко и быстро создавать 
полезные сетевые утилиты. 

Глава 4 посвящена двум темам. Сначала будет рассмотрено несколько инстру- 
ментальных средств, необходимых каждому сетевому программисту. Показано, как 
использовать утилиту р1па для диагностики простейших неисправностей. Затем 
рассказывается о сетевых анализаторах пакетов (зп1Нег) вообще и программе 
ссраитр в частности. В этой главе дано несколько примеров применения Е срдитр 
для диагностики сетевых проблем. С помощью программы + гасегоцее исследу- 
ется маленькая часть [егпей. 

Утилита ЕЕ ср, в создании которой принимал участие Майк Муусс (Мще Миизз) — 
автор программы р1 па, является полезным инструментом для изучения произво- 
дительности сети и влияния на нее тех или иных параметров ТСР. Будут проде- 
монстрированы некоторые методы диагностики. Еще одна бесплатная инструмен- 
тальная программа 1зоЕ необходима в ситуации, когда нужно сопоставить сетевые 
соединения с процессами, которые их открыли. Очень часто 1воЁ предоставляет 
информацию, получение которой иным способом потребовало бы поистине герои- 
ческих усилий. 

Много внимания уделено утилите пеё зв а и той разнообразной информации, 
которую можно получить с ее помощью, а также программам трассировки систем- 
ных вызовов, таким как КЕгасеи &гизе. 

Обсуждение инструментов диагностики сетей завершается построением ути- 
литы для перехвата и отображения датаграмм протокола 1СМР (протокол конт- 
роля сообщений в сети Пицегпей). Она не только вносит полезный вклад в ваш набор 
инструментальных средств, но и иллюстрирует использование простых сокетов (га\ 
зоске(з). 

Во второй части главы 4 описаны дополнительные ресурсы для пополнения 
знаний о ТСР/ТР и сетях. Я познакомлю вас с замечательными книгами Ричарда 
Стивенса, источниками исходных текстов, и собранием документов КЕС (предло- 
жений для обсуждения), размещенных на сервере проблемной группы проектиро- 
вания Пщегпее (Пцегпеё Епбшеепия Тазк Еогсе — ТЕТЕ) и в конференциях Озепе. 


Архитектура клиент-сервер 


Хотя постоянно говорится о клиентах и серверах, не всегда очевидно, какую 
роль играет конкретная программа. Иногда программы являются равноправными 
участниками обмена информацией, нельзя однозначно утверждать, что одна про- 
грамма обслуживает другую. Однако в случае с ТСР/Р различие более четкое. 
Сервер прослушивает порт, чтобы обнаружить входящие ТСР-соединения или 
ООР-датаграммы от одного или нескольких клиентов. С другой стороны, можно 
сказать, что клиент -— это тот, кто начинает диалог первым. 

В книге рассмотрены три типичных случая архитектуры клиент-сервер, пока- 
занные на рис. 1.1. В первом случае клиент и сервер работают на одной машине 
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(рис. 1.1а). Это самая простая конфигурация, поскольку нет физической сети. По- 
сылаемые данные, передаются стеку ТСР/ТР, но не помещаются в выходную оче- 
редь сетевого устройства, а закольцовываются системой и возвращаются обратно 
в стек, но уже в качестве принятых данных. 


Клиент 
Сервер 


а) клиент и сервер на одной машине 


б) клиент и сервер в локальной сети 


Рис. 1.1 
УММАМ Типичные примеры 
в) клиент и сервер в разных локальных сетях архитектуры клиент-сервер 


На этапе разработки такое размещение клиента и сервера дает определенные 
преимущества, даже если в реальности они будут работать на разных машинах. Во- 
первых, проще оценить производительность обеих программ, так как сетевые за- 
держки исключаются. Во-вторых, этот метод создает идеальную лабораторную 
среду, в которой пакеты не пропадают, не задерживаются и всегда приходят в пра- 
вильном порядке. 


Примечание По крайней мере, почти всегда. Как вы увидите в совете 7, даже 
в этой среде можно создать такую нагрузку, что ИОР-дата- 
граммы будут пропадать. 


И, наконец, разработку вести проще и удобнее, когда можно все отлаживать на 
одной машине. 

Разумеется, даже в условиях промышленной эксплуатации вполне возможно, 
что клиент и сервер будут работать на одном компьютере. В совете 26 описана та- 
кая ситуация. 

Во втором примере конфигурации (рис. 1.16) клиент и сервер работают на раз- 
ных машинах, но в пределах одной локальной сети. Здесь имеет место реальная 
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сеть, но условия все же близки к идеальным. Пакеты редко теряются и практичес- 
ки всегда приходят в правильном порядке. Такая ситуация очень часто встречает- 
ся на практике. Причем некоторые приложения предназначены для работы только 
в такой среде. 

Типичный пример - сервер печати. В небольшой локальной сети может быть 
только один такой сервер, обслуживающий несколько машин. Одна машина (или 
сетевое программное обеспечение на базе ТСР/]ТР, встроенное в принтер) высту- 
пает в роли сервера, который принимает запросы на печать от клиентов на других 
машинах и ставит их в очередь к принтеру. 

В третьем примере (рис. 1.1в) клиент и сервер работают на разных компь- 
ютерах, связанных глобальной сетью. Этой сетью может быть Ищегпе или кор- 
поративная [пёгапеф, но главное - приложения уже не находятся внутри одной 
локальной сети, так что на пути [Р-датаграмм есть, по крайней мере, один мар- 
шрутизатор. 

Такое окружение может быть более «враждебным», чем в первых двух случа- 
ях. По мере роста трафика в глобальной сети начинают переполняться очереди, 
в которых маршрутизатор временно хранит поступающие пакеты, пока не отпра- 
вит их адресату. А когда в очереди больше нет места, маршрутизатор отбрасыва- 
ет пакеты. В результате клиент должен передавать пакеты повторно, что приво- 
дит к появлению дубликатов и доставке пакетов в неправильном порядке. Эти 
проблемы возникают довольно часто, как вы увидите в совете 38. 

О различиях между локальными и глобальными сетями будет рассказано 
в совете 12. 


Элементы АР| сокетов 


В этом разделе кратко рассмотрены основы АР] сокетов и построены простейшие 
клиентское и серверное приложения. Хотя эти приложения очень схематичны, на их 
примере проиллюстрированы важнейшие характеристики клиента и сервера ТСР. 

Начнем с вызовов АР! необходимых для простого клиента. На рис. 1.2 показа- 
ны функции, применяемые в любом клиенте. Адрес удаленного хоста задается 
с помощью структуры зосКаа@х_1п, которая передается функции соппесеё. 

Первое, что вы должны сделать, — это получить сокет для логического соеди- 
нения. Для этого предназначен системный вызов зоскКее. 


#1пс1аае <зуз/воскее.и> /* ОМХ */ 
#1пс1аАе <и1пвосКк2.}Н> /* Мраомз */ 


ЗОСКЕТ зосКеё( 1п6 аота1п, 116 Буре, 116 ргоёосо]1 }; 


Возвращаемое значение: дескриптор сокета в случае успеха; —1 (ОМГХ) или 
ТМУАГТО_5ОСКЕТ (\Яп4о\ $) — оптибка. 


АР! сокетов не зависит от протокола и может поддерживать разные адресные 
домены. Параметр дота{п - это константа, указывающая, какой домен нужен со- 
кету. 
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Чаще используются домены АР_ТМЕТ (то есть Нцегпей) и АЕ_ТОСАГ (или 
АЕ_ОМТХ). В книге рассматривается только домен АЕ_ТМЕТ. Домен АР_ГОСА!, при- 
меняется для межпроцессного взаимодействия (ТРС) на одной и той же машине. 


Примечание Существуют разногласия по поводу того, следует ли обозначать 
константы доменов АЕ_* или РЕ_*. Сторонники РЕ_* указывают 
на их происхождение от уже устаревших вариантов вызова 
зоскеё в системах 4.1с/2.8/2.9В50. И, кроме того, они считают, 
что РЕ означает ртобосо! фату (семейство протоколов). Сторон- 
ники же АР_* говорят, что в коде ядра, относящемся к реализации 
сокетов, параметр Аота1п сравнивается именно с константами 
АЕ_*. Но, поскольку оба набора констант определены одинаково — 
в действительности одни константы просто выражаются через 
другие, — на практике можно употреблять оба варианта. 


С помощью параметра Еуре задается тип создаваемого сокета. Чаще встреча- 
ются следующие значения (а в этой книге только такие) сокетов: 


О 50СК_5ТВЕДМ — обеспечивают надежный 
дуплексный протокол на основе установ- 
ления логического соединения. Если гово- 
рится о семействе протоколов 'ТСРИТР, то 
это ТСР; 

О 50СК_ОСВАМ — обеспечивают ненадежный 
сервис доставки датаграмм. В рамках ГСР/ 


ТР это будет протокол (ОР; 


О $0СК_ВАМ —предоставляют доступ к неко- 
торым датаграммам на уровне протокола 
ТР. Они используются в особых случаях, 


например для просмотра всех 1СМР-сооб- Рис. 1.2. Основные вызовы 
щений. АР! сокетов для клиентов 


зоскааЯхг_1п{} 


Парная 
программа 


Параметр ргоЕосо1 показывает, какой про- 
токол следует использовать с данным сокетом. В контексте ТСР/[Р он обычно не- 
явно определяется типом сокета, поэтому в качестве значения задают 0. Иног- 
да, например в случае простых (га\) сокетов, имеется несколько возможных 
протоколов, так что нужный необходимо задавать явно. Об этом будет рассказано 
в совете 40. 

Для самого простого ТСР-клиента потребуется еще один вызов АР] сокетов, 
обеспечивающий установление соединения: 


#1пс1аае <зуз/зоскее.в> /* омтх */ 
#1пс1аае <илпвосКк2.Н> /* Уппаомв */ 


106 соппесе( ЗОСКЕТ 5, сопзЕ зегасе зосКка@Якг *реег, 1пЕ реег_1еп ); 


Возвращаемое значение: 0 — нормально, —1 (ИМХ) или не 0 (УМп4о\з) — 
ошибка. 


Введение 


Параметр $ - это дескриптор сокета, который вернул системный вызов восКек. 
Параметр реехг указывает на структуру, в которой хранится адрес удаленного хо- 
ста и некоторая дополнительная информация. Для домена АЕ_ТМЕТ - это структу- 
ра типа зоскаа@ах_1п. Ниже вы увидите, как она заполняется. Параметр реех_1еп 
содержит размер структуры в байтах, на которую указывает реег. 

После установления соединения можно передавать данные. В ОС МХ вы 
должны обратиться к системным вызовам геа@ и чк1 ке и передать им дескриптор 
сокета точно так же, как передали бы дескриптор открытого файла. Увы, как уже 
говорилось, в \Лп4о\з эти системные вызовы не поддерживают семантику соке- 
тов, поэтому приходится пользоваться вызовами гесу и зепа. Они отличаются от 
геад и ик1фе только наличием дополнительного параметра. 


#1пс1аае <зуз/взоскее.в> /* ОМХ */ 
#1ис1аае <и1лпзосКк2.18> /* Улпаоме */ 
116 гесу( ЗОСКЕТ 5, уо1ла *БиЕЁ, з12е_6 1еп, 116 Е1адв ); 


116 сепа( ЗОСКЕТ 5, сопзЕ уо1а *БиЕЁ, з12е_6 1еп, 106 Е1адв ); 


Возвращаемое значение: число принятых или переданных байтов в случае ус- 
пеха или —1 в случае ошибки. 


Параметры $, БиЁи 1еп означают то же, что и для вызовов геаа имх1 се. Зна- 
чение параметра Ё1ад в основном зависит от системы, но и ОМХ, и УЛп4о\з 
поддерживают следующие флаги: 


О М5С_ООВ - следует послать или принять срочные данные; 

О М5С_РЕЕК - используется для просмотра поступивших данных без их удале- 
ния из приемного буфера. После возврата из системного вызова данныееще 
могут быть получены при последующем вызове геа@ или гесу; 

О М$С_РОМТВООТЕ — сообщает ядру, что не надо выполнять обычный алгоритм 
маршрутизации. Как правило, используется программами маршрутизации 
или для диагностических целей. 


При работе с протоколом ТСР вам ничего больше не понадобится. Но при ра- 
ботес (ПР нужны еще системные вызовы гесуЕгом и зепасо. Они очень похожи 
на гесу и зепа, но позволяют при отправке датаграммы задать адрес назначения, 
а при приеме - получить адрес источника. 


#101с1ц4ае <зуз/воскее.н> /* омтх */ 
#1пс1аае <итпзоск2.Н> /* Иппаомв */ 


10Е гесуЕгом( СОСКЕТ 5, уо1а *БиЕЁ, з1хе_Е 1еп, 1пе ЕЁ]1ад$, 
$ЕкисЕ восКкКаааг *Егош, 1пЕ *Егоп1еп ); 


106 зепабо( ЗОСКЕТ 5, сопзЕ уо1а *БиЕ, в12е_Е 1]еп, 110 Е1а9$, 
сопзЕ зЕгисЕ соскааахг *Ео, 11Е Ео]1еп); 


Возвращаемое значение: число принятых или переданных байтов в случае ус- 
пеха или —1 при ошибке. 


Элементы АР! сокетов 


Первые четыре параметра - 5, БиЕ, 1еп и Е1ад$ - такие же, как в вызовах 
гесу и звепа. Параметр Егот в вызове гесуЁком указывает на структуру, в кото- 
рую ядро помещает адрес источника пришедшей датаграммы. Длина этого адреса 
хранится в целом числе, на которое указывает параметр Егот1еп. Обратите вни- 
мание, что Ёгот]1 еп - это указатель на целое. 

Аналогично параметр Ео в вызове зепа Ко указывает на адрес структуры, со- 
держащей адреса назначения датаграммы, а параметр Ео1еп - длина этого адреса. 
Заметьте, что Ео — это целое, а не указатель. 

В листинге 1.1 приведен пример простого ТСР-клиента. 


Листинг 1.1. Простейший ТСР-клиент 


51тр1ес.с 


1 НЗ ис1аае <зуз/вурез.[> 

2 #1пс1аае <зуз/воскее.й> 

3 #1ипс1аае <пее1пее/1т.1> 

4 #1ос1Таае <агра/1теё.й> 

5 #1ис1аае <вЕ@1о.0> 

6 1пЕ ша1п( уо1а ) 

7 { 

8 зЕгасЕе зоскаааг_1п реег; 

9 106 8; 

10 не те: 

11 срак БаЕЁ[ 1 ]; 

12 реег.51п_Ёаш11у = АЕР_ТМЕТ; 

13 реег.51п_рогЕ = Вопз( 7500 }; 

14 реег.з1п_аааг.в_а@аг = 1пеб_ ааак( "127.0.0.1" }; 
15 5 = восКеё( АЕ _ТМЕТ, 5ОСК_$ТВЕАМ, 0 ); 
16 1Е (8 <0) 

17 { 

18 реггог( "ошибка вызова зосКкеёе" }; 
19 ех1е (1 ); 

20 } 

21 гс = соппес®( $, ( взбгасЕ зоска@аг * )&5реег, з17еоЕЁ( реег ) ); 
22 1Е (тс) 

23 { 

24 реггог( "ошибка вызова соппес®" }; 
25 ех1е (1); 

26 } 


гс = зепа( <, "1", 1, 0); 
1Е (тс <= 0} 


реггог( "ошибка вызова зепа" ); 
ахев(- 1) 
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35 реккок( "ошибка вызова гкесу" ); 
36 е1зе 

37 ре1рЕЁЕ( "%с\п", БаЕ[ О] }; 

38 ех16 (0); 

39 } 


51тр1ес.с 


Клиент в листинге 1.1 написан как ОМХ-программа, чтобы не было сложнос- 
тей, связанных с переносимостью и УЛп4о\з-функцией ИА ах ор. В совете 4 
сказано, что в основном эти сложности можно скрыть в заголовочном файле, но 
сначала надо подготовить некоторые механизмы. Пока ограничимся более простой 
моделью О МХ. 


Подготовка адреса сервера 


12-14 Заполняем структуру зосКаЯ9к_1п, записывая в ее поля номер порта 
(7500) и адрес. 127.0.0.1 — это возвратный адрес, который означает, что 
сервер находится на той же машине, что и клиент. 


Получение сокета и соединение с сервером 


15-20 Получаем сокет типа $0СК_5ТВЕАМ. Как было отмечено выше, протокол 
ТСР, будучи потоковым, требует именно такого сокета. 

21-26 Устанавливаем соединение с сервером, обращаясь к системному вызо- 
ву соппесе. Этот вызов нужен, чтобы сообщить ядру адрес сервера. 


Отправка и получение одного байта 


27-38 Сначала посылаем один байт серверу, затем читаем из сокета один байт 
и записываем полученный байт в стандартный вывод и завершаем сеанс. 


Прежде чем тестировать клиента, необходим сервер. Вызовы АР! сокетов для 
сервера немного иные, чем для клиента. Они показаны на рис. 1.3. 

Сервер должен быть готов к установлению соединений с клиентами. Для это- 
го он обязан прослушивать известный ему порт с помощью системного вызова 
11з6еп. Но предварительно необходимо привязать адрес интерфейса и номер 
порта к прослушивающему сокету. Для этого предназначен вызов Ъ1п9: 


#1пс1аЯе <зуз/зоскее.в> /* ОМТХ */ 
#1пс1аае <им1пзосКк2.0> /* М1паомз */ 


106 Б1па( 5ОСКЕТ 5, сопзЕ зегисЕ зосКа@аг *пате, 1пе пате]1еп }; 


Возвращаемое значение: 0 — нормально, —1 (ОМХ) или $ОСКЕТ_ЕВВОВ (\Мп- 
4о\з) — ошибка. 


Параметр $ — это дескриптор прослушивающего сокета. С помощью парамет- 
ров пате и пате1еп передаются порт и сетевой интерфейс, которые нужно про- 
слушивать. Обычно в качестве адреса задается константа ТМАРОВ_АМУ. Это озна- 
чает, что будет принято соединение, запрашиваемое по любому интерфейсу. Если 
хосту с несколькими сетевыми адресами нужно принимать соединения только по 
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одному интерфейсу, то следует указать ГР-адрес этого интерфейса. Как обычно, 
пате]1еп - длина структуры зоскКааахг_1п. 

После привязки локального адреса к сокету нужно перевести сокет в режим 
прослушивания входящих соединений с помощью системного вызова 11з6 еп, на- 
значение которого часто не понимают. Его единственная задача - пометить сокет 
как прослушивающий. Когда хосту поступает запрос на установление соединения, 
ядро ищет в списке прослушивающих сокетов тот, для которого адрес назначения 
и номер порта соответствуют указанным в запросе. 


#1пс}аае <зуз/зоскее.п> /* ОМХ */ 
#1пс1ае <и1лпзосКк2.р> /* Илпаомз */ 


106 11зсеп( бОСКЕТ 5$, 106 БасА1оа ); 


Возвращаемое значение: 0 — нормально, —1 (ОМХ) или ЗОСКЕТ_ЕВВОК (МЙп- 
4о\з) — ошибка. 


Параметр $ — это дескриптор сокета, кото- 
рый нужно перевести в режим прослушивания. 
Параметр Баск1о9' — это максимальное число 
ожидающих, но еще не принятых соединений. 
Следует отметить, что это не максимальное 
число одновременных соединений с данным 
портом, а лишь максимальное число частично 
установленных соединений, ожидающих в оче- 
реди, пока приложение их примет (описание си- 
стемного вызова ассер{ дано ниже). 

Традиционно значение параметра Баск1о9 
не более пяти соединений, но в современных 
реализациях, которые должны поддерживать 
приложения с высокой нагрузкой, например, 
\!еЬ-сервера, оно может быть намного больше. 
Поэтому, чтобы выяснить его истинное значе- 
ние, необходимо изучить документацию по кон- 
кретной системе. Если задать значение, большее 
максимально допустимого, то система умень- 
шит его, не сообщив об ошибке. 

И последний вызов, который будет здесь Рис. 1.3, Основные вызовы 
рассмотрен, - это ассер+. Он служит для при- АР! сокетов для сервера 
ема соединения, ожидающего во входной оче- 
реди. После того как соединение принято, его можно использовать для передачи 
данных, например, с помощью вызовов гесу и зепа. В случае успеха ассере воз- 
вращает дескриптор нового сокета, по которому и будет происходить обмен дан- 
ными. Номер локального порта для этого сокета такой же, как и для прослушивающе- 
го сокета. Адрес интерфейса, на который поступил запрос о соединении, называется 
локальным. Адрес и номер порта клиента считаются удаленными. 


зоскаааг_1п{} 


—- Локально 


зоскаЯаг_1п{} 


РИ Парная 
программа 
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Обратите внимание, что оба сокета имеют один и тот же номер локального 
порта. Это нормально, поскольку ТСР-соединение полностью определяется че- 
тырьмя параметрами — локальным адресом, локальным портом, удаленным адре- 
сом и удаленным портом. Поскольку удаленные адрес и порт для этих двух соке- 
тов различны, то ядро может отличить их друг от друга. 


#10с1щае <зуз/воскее.Н> /* ПМТХ */ 
#1ис1аае <и1озосКк2.10> /* М1раомв */ 


106 ассере( ЗОСКЕТ 5, зЕгасЕ зоскКаааг *аа@ак, 106 *аааг]1ет }; 


Возвращаемое значение: 0 — нормально, —1 (ИМХ) или ТМУАЬТО_бОСКЕТ 
(УЛпдо\$) — ошибка. 


Параметр $ - это дескриптор прослушивающего сокета. Как показано на рис. 1.3, 
ассере возвращает адрес приложения на другом конце соединения в структуре 
зоскаааг _1п, на которую указывает параметр аааг. Целому числу, на которое 
указывает параметр аааг1еп, ядро присваивает значение, равное длине этой струк- 
туры. Часто нет необходимости знать адрес клиентского приложения, поэтому 
в качестве аааг и ааак1еп будет передаваться МОТ... 

В листинге 1.2 приведен простейший сервер. Эта программа также очень схе- 
матична, поскольку ее назначение - продемонстрировать структуру сервера и эле- 
ментарные вызовы АР] сокетов, которые обязан выполнить любой сервер. Обра- 
тите внимание, что, как и в случае с клиентом на рис. 1.2, сервер следует потоку 
управления, показанному на рис. 1.3. 


Листинг 1.2. Простой ТСР-сервер 


51тр1ез.с 


1 #1пс1аае <зуз/вурез.Н> 

2 #1пс1аае <зуз/звоскее.в> 

3 #1пс14аае <пеёе1птее/1т.В> 

4 #1пс1аае <з691о.Н> 

5 116 па1п( уо1а ) 

6 { 

7 з$ЕгисЕ зоскаЯаг_1п 1оса1; 

8 106 3; 

9 106 $1; 

10 106 кс; 

11 свак БаЕ[ 1 |; 

12 1оса1.$1п_Раш11у = АЕР_ТМЕТ; 

13 1оса1.$1п_рохгЕ = Нбоп$( 7500 ); 

14 1оса1.51п_аЯаг.з_аааг = Неоп1( ТМАШОВ_АМУ ); 
15 $5 = зоскее( АЕ _ТМЕТ, $ОСК_СТВЕАМ, 0); 
16 ВЕ 0} 

17 { 

18 реггог( "ошибка вызова зоскее" ); 
19 ех16 (1); 


элементы АР! сокетов 


ПТ 27 


20 } 

21 ус = Б1па( 5, ( зЕхгисЕ зосКа@аг * }&1оса1, з17еоЕЁ( 1оса1 ) }; 
22 1Е (тс < 0} 

23 { 

24 реггог( "ошибка вызова Б1па" )}; 
25 ех1е (1); 

26 } 

27 тс = 11°6еп(з, 5); 

28 И Пе 

29 { 

30 реггох( "ошибка вызова 11°$еп" }; 
31 ех1е (1 ); 

За } 


33 $1 = ассере( в, М, Ш ); 
34 1 (51 < 0) 


35 { 

36 регког( "ошибка вызова ассере" ); 
37 ех1Е (1 ); 

38 } 

39 гс = гесу( з1, БЕ, 1, 0}; 

40 1Е (с <= 0 ) 

41 { 

42 реггог( "ошибка вызова гесу" )}; 
43 ех1 (1); 

44 } 


45 РЕЕАЕЕГ. Жо", ВЕР О) 
46 ГС = зепа( з1, "2", 1,0); 
47 1Е (ус <=0 ) 


48 реггог( "ошибка вызова зепа" ); 
49 ех1 (0); 
50 } 


51тр]е5.с 


Заполнение адресной структуры и получение сокета 

12-20 Заполняем структуру зоскаааг_1п, записывая в ее поля известные ад- 
рес и номер порта, получаем сокет типа $ОСК_5ТВЕАМ, который и будет 
прослушивающим. 


Привязка известного порта и вызов {еп 


21-32 Привязываем известные порт и адрес, записанные в структуру 1оса1, 
к полученному сокету. Затем вызываем 115% еп, чтобы пометить сокет 
как прослушивающий. 


Принятие соединения 


33-39 Вызываем ассер® для приема новых соединений. Вызов ассерх бло- 
кирует выполнение программы до тех пор, пока не поступит запрос 


28 | | |111 Введение 


на соединение, после чего возвращает новый сокет для этого соеди- 
нения. 


Обмен данными 

39-49 Сначала читаем и печатаем байт со значением 1, полученный от клиента. 
Затем посылаем один байт со значением 2 назад клиенту и завершаем 
программу. 


Теперь можно протестировать клиент и сервер, запустив сервер в одном окне, 
а клиент — в другом. Обратите внимание, что сервер должен быть запущен пер- 
вым, иначе клиент аварийно завершится с сообщением СоппесЕ1оп геЕизея 
(В соединении отказано). 


Ьза: 5 в1ир1ес 
ошибка вызова соппесё: Соппесе1оп геЁазеа 
за: $ 


Ошибка произошла потому, что при попытке клиента установить соединение 
не было сервера, прослушивающего порт 7500. 

Теперь следует поступить правильно, то есть запустить сервер до запуска кли- 
ента: 


Ьза: $ в1тр1ев Ьза: $ вар1ес 


1 2 
за: $ Ьза: $ 
Резюме 


В этой главе приведен краткий обзор последующих глав и рассмотрены эле- 
менты АР] сокетов. Теперь можно перейти к более сложному материалу. 


Глава 2. Основы 


Совет 1. Различайте протоколы, 
требующие и не требующие 
установления логического соединения 


Один из фундаментальных вопросов сетевого программирования - это раз- 
личие между протоколами, требующими установления логического соединения 
(соппесвоп-опегке4 ргобосо|5), и протоколами, не требующими этого (соппесйоез 
ргофосо[$). Хотя ничего сложного в таком делении нет, но начинающие их часто пу- 
тают. Частично проблема кроется в выборе слов. Очевидно, что два компьютера дол- 
жны быть как-то «соединены», если необходимо наладить обмен данными между 
ними. Тогда что означает «отсутствие логического соединения»? 

О наличии и отсутствии логического соединения говорят применительно к иро- 
токолам. Иными словами, речь идет о способе передачи данных по физическому 
носителю, а не о самом физическом носителе. Протоколы, требующие и не требу- 
ющие логического соединения, могут одновременно разделять общий физический 
носитель; на практике обычно так и бывает. 

Ноесли это деление не имеет ничего общего с физическим носителем, по кото- 
рому передаются данные, то что же лежит в его основе? Главное различие в том, 
что в протоколах, не требующих соединения, каждый пакет передается независи- 
мо от остальных. Тогда как протоколы, устанавливающие соединение, поддержи- 
вают информацию о состоянии, которая позволяет следить за последовательнос- 
тью пакетов. 

При работе с протоколом, не требующим соединения, каждый пакет, именуемый 
датаграммой, адресуется и посылается приложением индивидуально (совет 30). 
С точки зрения протокола каждая датаграмма -— это независимая единица, не имею- 
щая ничего общего с другими датаграммами, которыми обмениваются приложения. 


Примечание Это не означает, что датаграммы независимы с точки зрения 
приложения. Если приложение реализует нечто более сложное, 
чем простой протокол запрос-ответ (клиент посылает серверу 
одиночный запрос и ожидает одиночного ответа на него), то, 
скорее всего, придется отслеживать состояние. Но суть в том, 
что приложение, а не протокол, отвечает за поддержание ин- 
формации о состоянии. Пример сервера, который не требует 
установления соединения, но следит за последовательностью 
датаграмм, приведен в листинге 3.6. 
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Обычно это означает, что клиент и сервер не ведут сложного диалога, — кли- 
ент посылает запрос, а сервер отвечает на него. Если позже клиент посылает но- 
вый запрос, то с точки зрения протокола это новая транзакция, не связанная 
с предыдущей. 

Кроме того, протокол не обязательно надежен, то есть сеть предпримет все воз- 
можное для доставки каждой датаграммы, но нет гарантий, что ни одна не будет 
потеряна, задержана или доставлена не в том порядке. 

С другой стороны, протоколы, требующие установления соединения, самосто- 
ятельно отслеживают состояние пакетов, поэтому они используются в приложе- 
ниях, ведущих развитый диалог. Сохраняемая информация о состоянии позволя- 
ет протоколу обеспечить надежную доставку. Например, отправитель запоминает, 
когда и какие данные послал, но они еще не подтверждены. Если подтверждение 
не приходит в течение определенного времени, отправитель повторяет передачу. 
Получатель запоминает, какие данные уже принял, и отбрасывает пакеты-дубли- 
каты. Если пакет поступает не в порядке очередности, то получатель может «при- 
держать» его, пока не придут логически предшествующие пакеты. 

У типичного протокола, требующего наличия соединения, есть три фазы. Сна- 
чала устанавливается соединение между двумя приложениями. Затем происходит 
обмен данными. И, наконец, когда оба приложения завершили обмен данными, 
соединение разрывается. 

Обычно такой протокол сравнивают с телефонным разговором, а протокол, 
не требующий соединения, - с отправкой письма. Каждое письмо запечатывается 
в отдельный конверт, на котором пишется адрес. При этом все письма оказывают- 
ся самостоятельными сущностями. Каждое письмо обрабатывается на почте неза- 
висимо от других посланий двух данных корреспондентов. Почта не отслеживает 
историю переписки, то есть состояние последовательности писем. Кроме того, не 
гарантируется, что письма не затеряются, не задержатся и будут доставлены в пра- 
вильном порядке. Это соответствует отправке датаграммы протоколом, не требу- 
ющим установления соединения. 


Примечание Хаверлок [НацепосЁ 2000] отмечает, что более правильная ана- 
логия - не письмо, а почтовая открытка, так как письмо с не- 
правильным адресом возвращается отправителю, а почтовая 
открытка - никогда (как и в типичном протоколе, не требую- 
щем наличия соединения). 


А теперь посмотрим, что происходит, когда вы не посылаете письмо другу, 
а звоните по телефону. Для начала набираете его номер. Друг отвечает. Некоторое 
время вы разговариваете, потом прощаетесь и вешаете трубки. Так же обстоит дело 
и в протоколе, требующем соединения. В ходе процедуры установления соедине- 
ния одна из сторон связывается с другой, стороны обмениваются «приветствия- 
ми» (на этом этапе они «договариваются» о тех параметрах и соглашениях, кото- 
рым будут следовать далее), и соединение вступает в фазу обмена данными. 

Во время телефонного разговора звонящий знает своего собеседника. И перед 
каждой фразой не нужно снова набирать номер телефона — соединение установлено. 


Необходимость логического соединения 


Аналогично в фазе передачи данных протокола, требующего наличия соединения, 
не надо передавать свой адрес или адрес другой стороны. Эти адреса -— часть ин- 
формации о состоянии, хранящейся вместе с логическим соединением. Остается 
только посылать данные, не заботясь ни об адресации, ни о других деталях, свя- 
занных с протоколом. 

Как и в разговоре по телефону, каждая сторона, заканчивая передачу данных, 
информирует об этом собеседника. Когда обе стороны договорились о завершении, 
они выполняют строго определенную процедуру разрыва соединения. 


Примечание Хотя указанная аналогия полезна, но она все же не точна. В те- 
лефонной сети устанавливается физическое соединение. А при- 
водимое «соединение» целиком умозрительно, оно состоит лишь 
из хранящейся на обоих концах информации о состоянии. Что- 
бы должным образом понять это, подумайте, что произойдет, 
если хост на одном конце соединения аварийно остановится 
и начнет перезагружаться. Соединение все еще есть? По отно- 
шению к перезагрузившемуся хосту - конечно, нет. Все соедине- 
ния установлены в его «прошлой жизни». Но для его бывшего <«со- 
беседника» соединение по-прежнему существует, так как у него 
все еще хранится информация о состоянии, и не произошло ни- 
чего такого, что сделало бы ее недействительной. 


В связи с многочисленными недостатками протоколов, не требующих соеди- 
нения, возникает закономерный вопрос: зачем вообще нужен такой вид протоко- 
лов? Позже вы узнаете, что часто встречаются ситуации, когда для создания 
приложения использование именно такого протокола оправдано. Например, 
протокол без соединения может легко поддерживать связь одного хоста со мно- 
гими и наоборот. Между тем протоколы, устанавливающие соединение, должны 
обычно организовать по одному соединению между каждой парой хостов. Важно 
то, что протоколы, не требующие наличия соединения, -— это 
фундамент, на котором строятся более сложные протоколы. 
Рассмотрим набор протоколов ТСР/Р. В совете 14 гово- 
рится, что ТСР/ТР - это четырехуровневый стек протоко- 
лов (рис. 2.1) етвНЯ 

Внизу стека находится интерфейсный уровень, который 
связан непосредственно с аппаратурой. Наверху располагают- 
ся такие приложения, как се1пеф, Еёр и другие стандартные Рис. 2.1 
и пользовательские программы. Как видно из рис. 2.1, ТСР Упрощенное 
и ОБР построены поверх ГР. Следовательно, !Р - это фунда- представление 
мент, на котором возведено все здание ТСР/ТР. Но [Р предо- стека протоколов 
ставляет лишь ненадежный сервис, не требующий установле- ТСРИР 
ния соединения. Этот протокол принимает пакеты с выше- 
расположенных уровней, обертывает их в {Р-пакет и направляет подходящему 
аппаратному интерфейсу для отправки в сеть. Послав пакет, [Р, как и все протоко- 
лы, не устанавливающие соединения, не сохраняет информацию о нем. 


Основы 


В этой простоте и заключается главное достоинство протокола [Р. Поскольку 
ГР не делает никаких предположений о физической среде передачи данных, он 
может работать с любым носителем, способным передавать пакеты. Так, [Р рабо- 
тает на простых последовательных линиях связи, в локальных сетях на базе техно- 
логий Е егрее и ТоКеп В1ле, в глобальных сетях на основе протоколов Х.25 и АТМ 
(АзупсВгопочз Тгапз{ег Моде — асинхронный режим передачи), в беспроводных 
сетях СОРР (Се]маг Пуэка!| Раскеё Рафа — сотовая система передачи пакетов циф- 
ровых данных) и во многих других средах. Хотя эти технологии принципиально 
различны, с точки зрения [Р они не отличаются друг от друга, поскольку способ- 
ны передавать пакеты. Отсюда следует важнейший вывод: раз [Р может работать 
в любой сети с коммутацией пакетов, То это относится и ко всему набору протоко- 
лов ТСР/ТР. 

А теперь посмотрим, как протокол ТСР пользуется этим простым сервисом, 
чтобы организовать надежный сервис с поддержкой логических соединений. По- 
скольку ТСР-пакеты (они называются сегментами) посылаются в составе ТР-да- 
таграмм, у ТСР нет информации, дойдут ли они до адреса, не говоря о возможно- 
сти искажения данных или о доставке в правильном порядке. Чтобы обеспечить 
надежность, ТСР добавляет к базовому [Р-сервису три параметра. Во-первых, в ГСР- 
сегмент включена контрольная сумма содержащихся в нем данных. Это позволяет 
в пункте назначения убедиться, что переданные данные не повреждены сетью во 
время транспортировки. Во-вторых, ТСР присваивает каждому байту порядковый 
номер, так что даже если данные прибывают в пункт назначения не в том порядке, 
в котором были отправлены, то получатель сможет собрать из них исходное сооб- 
щение. 


Примечание Разумеется, ТСР не передает порядковый номер вместе с каж- 
дым байтом. Просто в заголовке каждого ТСР-сегмента хра- 
нится порядковый номер первого байта. Тогда порядковые номе- 
ра остальных байтов можно вычислить. 


В-третьих, в ТСР имеется механизм подтверждения и повторной передачи, 
который гарантирует, что каждый сегмент когда-то будет доставлен. 

Из трех упомянутых выше добавлений механизм подтверждения/повторной 
передачи самый сложный, поэтому рассмотрим подробнее его работу. 


Примечание Здесь опускаются некоторые детали. Это обсуждение поверх- 
ностно затрагивает многие тонкости протокола ТСР и их при- 
менение для обеспечения надежного и отказоустойчивого транс- 
портного механизма. Более доступное и подробное изложение вы 
можете найти в ВЕС 793 [Розе! 19816] и КЕС 1122 [Вгааеп 
1989], в книге [5&е0епз 1994], В ВЕС 813 [С/атё 1982] обсужда- 
ется механизм окон и подтверждений ТСР. 


На каждом конце ТСР-соединения поддерживается окно приема, представляю- 
щее собой диапазон порядковых номеров байтов, который получатель готов принять 
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от отправителя. Наименьшее значение, соответствующее левому краю окна, - это 
порядковый номер следующего ожидаемого байта. Наибольшее значение, соответ- 
ствующее правому краю окна, — это порядковый номер последнего байта, для ко- 
торого У ТСР есть место в буфере. Использование окна приема (вместо посылки 
только номера следующего ожидаемого байта) повышает надежность протокола 
за счет предоставления средств управления потоком. Механизм управления пото- 
ком предотвращает переполнение буфера ТСР. 

Когда прибывает ТСР-сегмент, все байты, порядковые номера которых оказы- 
ваются вне окна приема, отбрасываются. Это касается как ранее принятых данных 
(с порядковым номерами левее окна приема), так и данных, для которых нет места 
в буфере (с порядковым номерами правее окна приема). Если первый допустимый 
байт в сегменте не является следующим ожидаемым, значит, сегмент прибыл не по 
порядку. В большинстве реализаций ТСР такой сегмент помещается в очередь 
и находится в ней, пока не придут пропущенные данные. Если же номер первого 
допустимого байта совпадает со следующим ожидаемым, то данные становятся 
доступными для приложения, а порядковый номер следующего ожидаемого байта 
увеличивается на число байтов в сегменте. В этом случае считается, что окно сдви- 
гается вправо на число принятых байтов. Наконец, ТСР посылает отправителю 
подтверждение (сегмент АСК), содержащее порядковый номер следующего ожи- 
даемого байта. 

Например, на рис. 2.2а окно приема обведено пунктиром. Вы видите, что по- 
рядковый номер следующего ожидаемого байта равен 4, и ТСР готов принять 
9 байт (с 4 по 12). На рис. 2.26 показано окно приема после поступления байтов 
с номерами 4-7. Окно сдвинулось вправо на четыре номера, а в сегменте АСК, 
который пошлет ТСР, номер следующего ожидаемого байта будет равен 8. 


Окно приема 


ал Сета тете ТТ ори нзрар еее 


=... 


о [ТеТэТаТТе Гете Тэ от аэрарее тес 


_------Ы 


Рис. 2.2. Окно приема ТСР 


Теперь рассмотрим эту же ситуацию с точки зрения протокола ТСР на посыла- 
ющем конце. Помимо окна приема, ТСР поддерживает также окно передачи, разде- 
ленное на две части. В одной из них расположены байты, которые уже отосланы, но 
еще не подтверждены, а в другой — байты, которые еще не отправлены. Предполага- 
ется, что на байты 1-3 уже пришло подтверждение, поэтому на рис. 2.За изображено 
окно Передачи, соответствующее окну приема на рис. 2.2а. На рис. 2.36 вы видите 
окно передачи после пересылки байтов 4-7, но до прихода подтверждения. ТСР еще 
может послать байты 8—12, не дожидаясь подтверждения от получателя. После от- 
правки байтов 4-7 ТСР начинает отсчет тайм-аута ретрансмиссии (гегап$1115$$10п 
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итеоце — ВТО). Если до срабатывания таймера не пришло подтверждение на все 
четыре байта, ТСР считает, что они потерялись, и посылает их повторно. 


Примечание Поскольку в многих реализациях не происходит отслеживания 
710г0, какие байты были посланы в конкретном сегменте, может 
случиться, что повторно переданный сегмент содержит боль- 
ше байтов, чем первоначальный. Например, если байты 8 и 9 
были посланы до срабатывания КТО-таймера, то такие реали- 
зации повторно передадут байты с 4 по 9. 


Обратите внимание, что срабатывание КТО-таймера не означает, что исходные 
данные не дошли до получателя. Например, может потеряться АСК-сегмент 
с подтверждением или исходный сегмент задержаться в сети на время, большее чем 
тайм-аут ретрансмиссии. Но ничего страшного в этом нет, так как если первона- 
чально отправленные данные все-таки прибудут, то повторно переданные окажут- 
ся вне окна приема ТСР и будут отброшены. 

После получения подтверждения на байты 4-7 передающий ТСР «забывает» 
про них и сдвигает окно передачи вправо, как показано на рис. 2.3в. 


Окно приема 
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в) БАС ЕТЕЛ Е ЕНОТ ЕЛ КО БЕ СЕБЕ ЕО БЕ КЕ 


= -------— 


Эти байты можно посылать 


Рис. 2.3. Окно передачи ТСР 


ТСР обеспечивает прикладного программиста надежным протоколом, требу- 
ющим установления логических соединений. О таком протоколе рассказывается 
в совете 9. 

С другой стороны, ООР предоставляет программисту ненадежный сервис, не 
требующий соединения. Фактически ОПР добавляет лишь два параметра к про- 
токолу ГР, поверх которого он построен. Во-первых, необязательную контрольную 
сумму для обнаружения искаженных данных. Хотя у самого протокола [Р тоже 
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есть контрольная сумма, но вычисляется она только для заголовка [Р-пакета, по- 
этому ТСР и ОПР также включают контрольные суммы для защиты собственных 
заголовков и данных. Во-вторых, (ЮР добавляет к [Р понятие порта. 

Для отправки [Р-датаграммы конкретному хосту используются [Р-адреса, то 
есть адреса, которые обычно приводятся в стандартной десятичной нотации Пегпе 
(совет 2). Но по прибытии на хост назначения датаграмму еще необходимо доста- 
вить нужному приложению. Например, один ОПР-пакет может быть предназна- 
чен для сервиса эхо-контроля, а другой - для сервиса «время дня». Порты как раз 
и дают способ направления данных нужному приложению (этот процесс называ- 
ют демультиплексированием). С каждым ТСР и ОПР-сокетом ассоциирован но- 
мер порта. Приложение может явно указать этот номер путем обращения к сис- 
темному вызову Ь1п9 или поручить операционной системе выбор порта. Когда 
пакет прибывает, ядро «ищет» в списке сокетов тот, который ассоциирован с про- 
токолом, парой адресов и парой номеров портов, указанных в пакете. Если сокет 
найден, то данные обрабатываются соответствующим протоколом (в примерах 
ТСР или ОБР) и передаются тем приложениям, которые этот сокет открыли. 


Примечание Если сокет открыт несколькими процессами или потоками 
((йтеаа), то данные может считывать только один из них, 
остальным они будут недоступны. 


Возвращаясь к аналогии с телефонными переговорами и письмами, можно ска- 
зать, что сетевой адрес в ТСР-соединении подобен номеру телефона офисной АТС, 
а номер порта - это добавочный номер конкретного телефона в офисе. Точно так 
же ПОР-адрес можно представить как адрес многоквартирного дома, а номер пор- 
Та - как отдельный почтовый ящик в его подъезде. 


Резюме 


В этом разделе обсуждены различия между протоколами, которые требуют 
и не требуют установления логического соединения. Вы узнали, что ненадежные 
протоколы, в которых происходит обмен датаграммами без установления соеди- 
нения, — это фундамент, на котором строятся надежные протоколы на базе соеди- 
нений. Попутно было кратко изложено, как надежный протокол ТСР строится на 
основе ненадежного протокола [Р. 

Также отмечалось, что понятие «соединение» в ТСР носит умозрительный ха- 
рактер. Оно состоит из хранящейся информации о состоянии на обоих концах; ни- 
какого «физического» соединения, как при телефонном разговоре, не существует. 


Совет 2. Выясните, что такое подсети и СОК 


Длина [Р-адреса (в версии ГРу4) составляет 32 бита. Адреса принято записы- 
вать в десятичной нотации — каждый из четырех байт представляется одним деся- 
тичным числом, которые отделяются друг от друга точками. Так, адрес 0х11345678 
записывается в виде 17.52.86.120. При записи адресов нужно учитывать, что в не- 
которых реализациях ТСР/ТР принято стандартное для языка С соглашение о том, 


ЕТ: В В ВВ В И Основы 


что числа, начинающиеся с нуля, записываются в восьмеричной системе. В таком 
случае 17.52.86.120 - это не то же самое, что 017.52.86.120. В первом примере ад- 
рес сети равен 17, а во втором - 15. 


Классы адресов 


По традиции все [Р-адреса подразделены на пять классов, показанных на рис. 2.4. 

Адреса класса О используются для группового вещания, а класс Е зарезерви- 
рован для будущих расширений. Остальные классы - А, Ви С - предназначены 
для адресации отдельных сетей и хостов. 


01 78 3 
Класс А аы Идентификатор хоста 

0 2 15 16 31 
Класс В 08 Идентификатор сети Идентификатор хоста 


3 23 24 31 


0 
Идентификатор 
Класс С 008 Идентификатор сети 
0 3 
Класс О 0058 Для группового вещания 
0 
Класс Е ВЫ Зарезервировано 


Рис. 2.4. Классы !Р-адресов 


— 


Класс адреса определяется числом начальных единичных битов. У адресов 
класса А вообще нет бита 1 в начале, у адресов класса В — один такой бит, у адре- 
сов класса С — два и тд. Идентификация класса адреса чрезвычайно важна, 
поскольку от этого зависит интерпретация остальных битов адреса. 

Остальные биты любого адреса классов А, В и С разделены на две группы 
Первая часть любого адреса представляет собой идентификатор сети, вторая -— 
идентификатор хоста внутри этой сети. 


Примечание Биты идентификации класса также считаются частью иден- 
тификатора сети. Так, 130.50.10.200 — это адрес класса В, в ко- 
тором идентификатор сети равен 0х8232. 


Смысл разбивки адресного пространства на классы в том, чтобы обеспечить 
необходимую гибкость, не теряя адресов Например, класс А позволяет адресовать 
сети с огромным (16777214) количеством хостов. 
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Примечание Существует 2“, или 16777216 возможных идентификаторов 
хостов, но адрес 0 и адрес, состоящий из одних единиц, имеют 
специальный смысл. Адрес из одних единиц — это широковеща- 
тельный адрес. [Р-датаграммы, посланные по этому адресу, до- 
ставляются всем хостам в сети. Адрес 0 означает «этот хост» 
и используется хостом как адрес источника, которому в ходе про- 
цедуры начальной загрузки необходимо определить свой истин- 
ный сетевой адрес. Поэтому число хостов в сети всегда равно 
2" — 2, где п — число бит в части адреса, относящейся к хосту. 


Поскольку в адресах класса А под идентификатор сети отводятся 7 бит, то все- 
го существует 128 сетей класса А. 


Примечание Как и в случае идентификаторов хостов, два из этих адресов за- 
резервированы. Адрес 0 означает «эта сеть» и, аналогично хос- 
ту 0, используется для определения адреса сети в ходе начальной 
загрузки. Адрес 127 — это адрес «собственной» сети хоста. Да- 
таграммы, адресованные сети 127, не должны покидать хост- 
отправитель. Часто этот адрес называют «возвратным» (10ор- 
фасЁ) адресом, поскольку отправленные по нему датаграммы 
«возвращаются» на тот же самый хост. 


На другом полюсе располагаются сети класса С. Их очень много, но в каждой 
может быть не более 254 хостов. Таким образом, адреса класса А предназначены 
для немногих гигантских сетей с миллионами хостов, тогда как адреса класса С — 
для миллионов сетей с небольшим количеством хостов. 

В табл. 2.1 показано, сколько сетей и хостов может существовать в каждом 
классе, а также диапазоны допустимых адресов. Будем считать, что сеть 127 
принадлежит классу А, хотя на самом деле она, конечно, недоступна для адре- 
сации. 


Таблица 2.1. Число сетей, хостов и диапазоны адресов для классов А, Ви С 


Класс Сети Хосты Диапазон адресов 

А 127 16 777 214 0.0.0.1-127.255.255.255 

В 16 384 65 534 128.0.0.0-191.255.255.255 
С 2097 252 254 192.0.0.0-223.255.255.255 


Первоначально проектировщики набора протоколов ТСР/ТР полагали, что 
сети будут исчисляться сотнями, а хосты — тысячами. 


Примечание В действительности, как отмечается в работе [Нийета 1995}, 
в исходном проекте фигурировали только адреса, которые те- 
перь относятся к классу А. Подразделение на три класса было 
сделано позже, чтобы иметь более 256 сетей. 


ЕТ: И ВИ В ИВ Основы 


Появление дешевых, повсеместно применяемых персональных компьютеров 
привело к значительному росту числа сетей и хостов. Нынешний размер Пщегпей 
намного превосходит ожидания его проектировщиков. 

Такой рост выявил некоторые недостатки классов адресов. Прежде всего, 
число хостов в классах А и В слишком велико. Вспомним, что идентификатор 
сети, как предполагалось, относится к физической сети, например локальной. 
Но никто не станет строить физическую сеть из 65000 хостов, не говоря уже 
о 16000000. Вместо этого большие сети разбиваются на сегменты, взаимосвя- 
занные маршрутизаторами. 

В качестве простого примера рассмотрим два сегмента сети, изображенной 
на рис. 2.5. 


К |мете! 


Сегмент 1 


Сегмент 2 


Рис. 2.5. Сеть из двух сегментов 


Если хосту Н1 нужно обратиться к хосту Н2, то он получает физический ад- 
рес, соответствующий [Р-адресу Н2 (используя для этого метод, свойственный 
данной реализации физической сети), и помещает датаграмму «на провод». 

А если хосту Н1 необходимо обратиться к хосту НЗ? Напрямую послать дата- 
грамму невозможно, даже если известен физический адрес получателя, поскольку Н1 
и НЗ находятся в разных сетях. Поэтому Н1 должен отправить датаграмму через 
маршрутизатор В1. Если у двух сегментов разные идентификаторы сетей, то Н1 
по своей маршрутной таблице определяет, что пакеты, адресованные сегменту 2, 
обрабатываются маршрутизатором ЁВ1, и отправляет ему датаграмму в предполо- 
жении, что тот переправит ее хосту НЗ. 

Итак, можно назначить двум сегментам различные идентификаторы сети. Но 
есть и другие решения в рамках системы адресных классов. Во-первых, маршрут- 
ная таблица хоста Н1 может содержать по одному элементу для каждого хоста 
в сегменте 2, который определит следующего получателя на пути к этому хосту — 
В1. Такая же таблица должна размещаться на каждом хосте в сегменте 1. Анало- 
гичные таблицы, описывающие достижимость хостов из сегмента 1, следует поме- 
стить на каждом хосте из сегмента 2. Очевидно, такое решение плохо масштаби- 
руется при значительном количестве хостов. Кроме того, маршрутные таблицы 
придется вести вручную, что очень скоро станет непосильной задачей для админи- 
стратора. Поэтому на практике такое решение почти никогда не применяется. 
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Во-вторых, можно реализовать АКР-прокси (ргоху АВР) таким образом, что- 
бы В1 казался для хостов из сегмента 1 одновременно НЗ, Н4 и Н5, а для хостов 
из сегмента 2 — Н1, Н2и В2. 


Примечание Агента АЁР в англоязычной литературе еще называют ртот!5- 
сиоиз АЕР (пропускающий АЕР) или АЕР расЁ (трюк АВР). 


Это решение годится только в случае, когда в физической сети используется 
протокол АБР (Аа4гез$ Везоийоп Ргофосо| — протокол разрешения адресов) для 
отображения [Р-адресов на физические адреса. В соответствии с АКР хост, кото- 
рому нужно получить физический адрес, согласующийся с некоторым [Р-адресом, 
должен послать широковещательное сообщение с просьбой хосту, обладающему 
данным [Р-адресом, выслать свой физический адрес. АКР-запрос получают все 
хосты в сети, но отвечает только тот, [Р-адрес которого совпадает с запрошенным. 

Если применяется агент АКР то в случае, когда хосту Н1 необходимо послать 
[Р-датаграмму НЗ, физический адрес которого неизвестен, он посылает АКР- 
запрос физического адреса НЗ. Но НЗ этот запрос не получит, поскольку нахо- 
дится в другой сети. Поэтому на запрос отвечает его агент — К1, сообщая свой 
собственный адрес. Когда В1 получает датаграмму, адресованную НЗ, он пере- 
правляет ее конечному адресату. Все происходит так, будто НЗ и Н1 находятся 
в одной сети. 

Как уже отмечалось, агент АКР может работать только в сетях, которые ис- 
пользуют протокол АКР и к тому же имеют сравнительно простую топологию. 
Подумайте, что случится при наличии нескольких маршрутизаторов, соединяю- 
щих сегменты 1 и 2. 

Извышесказанного следует, что общий способ организовать сети с нескольки- 
ми сегментами - это назначить каждому сегменту свой идентификатор сети. Но 
у этого решения есть недостатки. Во-первых, при этом возможна потеря многих ад- 
ресов в каждой сети. Так, если у любого сегмента сети имеется свой адрес класса В, 
то большая часть [Р-адресов просто не будет использоваться. 

Во-вторых, маршрутная таблица любого узла, который направляет датаграм- 
мы напрямую в комбинированную сеть, должна содержать по одной записи для 
каждого сегмента. В указанном примере это не так страшно. Но вообразите сеть из 
нескольких сотен сегментов, а таких сетей может быть много. Понятно, что разме- 
ры маршрутных таблиц станут громадными. 


Примечание Эта проблема более серъезна, чем может показаться на первый 
взгляд. Объем памяти маршрутизаторов обычно ограничен, 
и нередко маршрутные таблицы размещаются в памяти специ- 
ального назначения на сетевых картах. Реальные примеры от- 
каза маршрутизаторов из-за роста маршрутных таблиц рас- 
сматриваются в работе [Нийета 1995], 


Обратите внимание, что эти проблемы не возникают при наличии хотя бы од- 
ного идентификатора сети. [Р-адреса не остаются неиспользованными, поскольку 
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при потребности в новых хостах можно всегда добавить новый сегмент. С другой сто- 
роны, так как имеется лишь один идентификатор сети, в любой маршрутной таблице 
необходима всего одна запись для отправки датаграмм любому хосту в этой сети. 


Подсети 


Мне хотелось найти решение, сочетающее два достоинства: во-первых, неболь- 
шие маршрутные таблицы и эффективное использование адресного пространства, 
обеспечиваемые единым идентификатором сети, во-вторых, простота маршрути- 
зации, характерная для сетей, имеющих сегменты с разными идентификаторами 
сети. Желательно, чтобы внешние хосты «видели» только одну сеть, а внутрен- 
ние -— несколько сетей, по одной для каждого сегмента. 

Это достигается с помощью механизма подсетей. Идея очень проста. Посколь- 
ку внешние хосты для принятия решения о выборе маршрута используют только 
идентификатор сети, администратор может распределять идентификаторы хостов 
по своему усмотрению. Таким образом, идентификатор хоста — это закрытая 
структура, не имеющая вне данной сети интерпретации. 

Разделение на подсети осуществляется по следующему принципу. Одна часть 
идентификатора хоста служит для определения сегмента (то есть подсети), в со- 
став которого входит хост, а другая — для идентификации конкретного хоста. Рас- 
смотрим, например, сеть класса В с адресом 190.50.0.0. Можно считать, что третий 
байт адреса — это идентификатор подсети, а четвертый байт -— номер хоста в этой 
подсети. На рис. 2.ба приведена сгруктура адреса с точки зрения внешнего компь- 
ютера. Идентификатор хоста — это поле с заранее неизвестной структурой. На 
рис. 2.66 показано, как эта структура выглядит изнутри сети. Вы видите, что она 
состоит из идентификатора подсети и номера хоста. 


0 15 16 31 
15 16 23 24 31 Рис. 2.6 


Два взгляда на адрес сети 
ти ть Номе 
Идентификатор сети Подсе мер хоста класса В с подсетями 


В приведенном примере взят адрес класса В, и поле номера хоста выделено по 
границе байта. Но это необязательно. На подсети можно разбивать сети классов 
А, ВиС и часто не по границе байта. С каждой подсетью ассоциируется маска под- 
сети, которой определяется, какая часть адреса отведена под идентификаторы сети 
и подсети, а какая — под номер хоста. Так, маска подсети для примера, показанно- 
го на рис. 2.66, будет ОхНННО0. В основном маска записывается в десятичной но- 
тации (255.255.255.0), но если разбивка проходит не по границе байта, то удобнее 
первая форма. 


Примечание Обратите внимание, что, хотя говорится о маске подсети, фак- 
тически она выделяет части, относящиеся как к сети, так и к под- 
сети, то есть все, кроме номера хоста. 
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Предположим, что для идентификатора подсети отведено 10 бит, а для номе- 
ра хоста — 6 бит. Тогда маска подсети будет 255.255.255.192 (ОхННс0). Как следу- 
ет из рис. 2.7, в результате наложения этой маски на адрес 190.50.7.75 получается 
номер сети/подсети, равный 190.70.7.64. 

Для проверки убедитесь, что адрес 190.50.7.75 принадлежит хосту 11 в под- 
сети 29 сети 190.50.0.0. Важно не забывать, что эта интерпретация имеет смысл 
только внутри сети. Для внешнего мира адрес интерпретируется как хост 1867 
в сети 190.50.0.0. 

Теперь следует выяснить, как маршрутизаторы на рис. 2.5 могут воспользо- 
ваться структурой идентификатора хоста для рассылки датаграмм внутри сети. 
Предположим, что есть сеть класса В с адресом 190.5.0.0 и маска подсети равна 
255.255.255.0. Такая структура показана на рис. 2.66. 


190 50 Е 75 


|Р-адрес | 10111110 00110010 00000111 | 01001011 


Маска подсети 11111111 11111111 11111111 11000000 


Сеть/подсеть | 10111110 | 00110010 | 00000111 | 01000000 


190 50 7 64 


Рис. 2.7. Наложение маски подсети с помощью операции АМО 
для выделения сетевой части {Р-адреса 


Нарис. 2.8 первому сегменту назначен идентификатор подссти 1, а второму - иден- 
тификатор подсети 2. Рядом с сетевым интерфейсом каждого хоста указан его [Р-адрес. 
Обратите внимание, что третий байт каждого адреса — это номер подсети, которой при- 
надлежит интерфейс. Однако внешнему компьютеру эта интерпретация неизвестна. 


190.50.0.0 


190.50.2.1 190.50.2,2 190.50.2.3 190.50.2.4 


190.50.2.0 


Рис. 2.8. Сеть с подсетями 


Возвращаясь к вышесказанному, следует выяснить, что происходит, когда хосту 
Н1 нужно обратиться к хосту НЗ. Н1 берет адрес НЗ (190.50.2.1) и накладывает на 
него маску подсети (255.255.255.0), получая в результате 190.5.2.0. Поскольку Н1 на- 
ходится в подсети 190.5.1.0, то НЗ напрямую недоступен, поэтому он сверяется со сво- 
ей маршрутной таблицей и обнаруживает, что следующий адрес на пути к НЗ - это В1. 
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Примечание Во многих реализациях эти два шага объединены за счет поме- 
щения в маршрутную таблицу обеих подсетей. При поиске мар- 
шрута [Р выявляет одно из двух: либо целевая сеть доступна 
непосредственно, либо датаграмму надо отослать промежуточ- 
ному маршрутизатору. 


Затем Н1 отображает ГР-адрес К1 на его физический адрес (например, с помо- 
щью протокола АВР) и посылает В1 датаграмму. К1 ищет адрес назначения в своей 
маршрутной таблице, пользуясь той же маской подсети, и определяет местонахож- 
дение НЗ в подсети, соединенной с его интерфейсом 190.50.2.4. После чего В1 до- 
ставляет датаграмму хосту Н3, получив предварительно его физический адрес по 1Р- 
адресу, — для этого достаточно передать датаграмму сетевому интерфейсу 190.50.2.4. 

А теперь предположим, что Н1 необходимо отправить датаграмму Н2. При 
наложении маски подсети на адрес Н2 (190.5.1.2) получается 190.50.1.0, то есть та 
же подсеть, в которой находится сам хост Н1. Поэтому Н1 нужно только получить 
физический адрес Н2 и отправить ему датаграмму напрямую. 

Далее разберемся, что происходит, когда хосту Е из внешней сети нужно отпра- 
вить датаграмму НЗ. Поскольку 190.50.2.1 — адрес класса В, то маршрутизатору на 
границе сети хоста Е известно. что НЗ находится в сети 190.50.0.0. Так как шлюзом 
в эту сеть является В2, рано или поздно датаграмма от хоста ЕЁ дойдет до этого мар- 
шрутизатора. С этого момента все совершается так же, как при отправке датаграм- 
мы хостом Н1: 2 накладывает маску, выделяет адрес подсети 190.50.2.0, определя- 
ет В] в качестве следующего узла на пути к НЗ и посылает К1 датаграмму, которую 
тот переправляет НЗ. Заметьте, что хосту Е неизвестна внутренняя топология сети 
190.50.0.0. Он просто посылает датаграмму шлюзу К2. Только В2 и другие хосты 
внутри сети определяют существование подсетей и маршруты доступа к ним. 

Важный момент, который нужно помнить, — маска подсети ассоциируется с се- 
тевым интерфейсом и, следовательно, с записью в маршрутной таблице. Это озна- 
чает, что разные подсети в принципе могут иметь разные маски. 

Предположим, что адрес класса В 190.50.0.0 принадлежит университетской сети, 
а каждому факультету выделена подсеть с маской 255.255.255.0 (на рис. 2.8 показа- 
на только часть всей сети). Администратор факультета информатики, которому на- 
значена подсеть 5, решает выделить один сегмент сети Ефсгпе компьютерному 
классу, а другой — всем остальным факультетским компьютерам. Он мог бы потре- 
бовать у администрации университета еще один номер подсети, но в компьютер- 
ном классе всего несколько машин, так что нет смысла выделять ему адресное про- 
странство, эквивалентное целой подсети класса С. Вместо этого он предпочел 
разбить свою подсеть на два сегмента, то есть создать подсеть внутри подсети. 

Для этого он увеличивает длину поля подсети до 10 бит и использует маску 
255.255.255.192. В результате структура адреса выглядит, как показано на рис. 2.9. 

Старшие 8 бит идентификатора подсети всегда равны 0000 0101 (5), поскольку 
основная сеть адресует всю подсеть как подсеть 5. Биты Х и У определяют, какой 
Еегпе!-сегмент внутри подсети 190.50.5.0 адресуется. Из рис. 2.10 видно, что если 
ХУ = 10, то адресуется подсеть в компьютерном классе, а если ХУ = 01 — оставшаяся 
часть сети. Частично топология подсети 190.50.5.0 изображена на рис. 2.10. 


Ограниченное вещание 
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Идентификатор сети Идентификато Хост 
ТЕ деи для подсети 190.50.5.0 


В верхнем сегменте (подсеть 190.50.1.0) на рис. 2.10 расположен маршрутиза- 
тор Е2, обеспечивающий выход во внешний мир, такой же, как на рис. 2.8. Под- 
сеть 196.50.2.0 здесь не показана. Средний сегмент (подсеть 190.50.5.128) — это локаль- 
ная сеть Ефегпей в компьютерном классе. Нижний сегмент (подсеть 190.50.5.64) — это 
сеть Ефегпеё, объединяющая остальные факультетские компьютеры. Для упрощения 
номер хоста каждой машины один и тот же для всех ее сетевых интерфейсов и совпада- 
ет с числом внутри прямоугольника, представляющего хост или маршрутизатор. 


190.50.0.0 


190.50.5.130 


190.50.5.128 


190.50.5.66 190.50.5.67 


190.50.5.65 


190.50.5.64 


Рис. 2.10. Подсеть внутри подсети 


Маска подсети для интерфейсов, подсоединенных к подсетям 190.50.5.64 
и 190.50.5.128, равна 255.255.255.192, а к подсети 190.50.1.0 — 255.255.255.0. 

Эта ситуация в точности аналогична предыдущей, которая рассматривалась 
для рис. 2.8. Так же, как хостам вне сети 190.50.0.0 неизвестно то, что третий байт 
адреса определяет подсеть, так и хосты в сети 190.50.0.0, но вне подсети 190.50.5.0, 
не могут определить, что первые два бита четвертого байта задают подсеть подсе- 
ти 190.50.5.0. 

Теперь кратко остановимся на широковещательных адресах. При использова- 
нии подсетей существует четыре типа таких адресов для вещания: ограниченный, 
на сеть, на подсеть и на все подсети. 


Ограниченное вещание 


Адрес для ограниченного вещания - 255.255.255.255. Вещание называется огра- 
ниченным, поскольку датаграммы, посланные на этот адрес, не уходят дальше 
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маршрутизатора. Они ограничены локальным кабелем. Такое широковещание при- 
меняется, главным образом, во время начальной загрузки, если хосту неизвестен 
свой [Р-адрес или маска своей подсети. 

Процесс передачи широковещательной датаграммы хостом, имеющим несколь- 
ко сетевых интерфейсов, зависит от реализации. Во многих реализациях датаграм- 
ма отправляется только по одному интерфейсу. Чтобы приложение отправило 
широковещательную датаграмму по нескольким интерфейсам, ему необходимо 
узнать у операционной системы, какие интерфейсы сконфигурированы для под- 
держки широковещания. 


Вещание на сеть 


В адресе для вещания на сеть идентификатор сети определяет адрес этой сети, 
а идентификатор хоста состоит из одних единиц. Например, для вещания на сеть 
190.50.0.0 используется адрес 190.50.255.255. Датаграммы, посылаемые на такой 
адрес, доставляются всем хостам указанной сети. 

Требования к машрутизаторам (ВЕС 1812) [ВаКег 1995] предусматривают по 
умолчанию пропуск маршрутизатором сообщений, вещаемых на сеть, но эту воз- 
можность можно отключить. Во избежание атак типа «отказ от обслуживания» 
(Чегша| оЁзегусе), которые используют возможности, предоставляемые направленным 
широковещанием, во многих маршрутизаторах пропуск таких датаграмм, скорее 
всего, будет заблокирован. 


Вещание на подсеть 


В адресе для вещания на все подсети идентификаторы сети и подсети опреде- 
ляют соответствующие адреса, а идентификатор хоста состоит из одних единиц. 
Не зная маски подсети, невозможно определить, является ли данный адрес адре- 
сом для вещания на подсеть. Например, адрес 190.50.1.255 можно трактовать как 
адрес для вещания на подсеть только при условии, если маршрутизатор имеет ин- 
формацию, что маска подсети равна 255.255.255.0. Если же известно, что маска 
подсети равна 255.255.0.0, то это адрес не считается широковещательным. 

При использовании бесклассовой междоменной маршрутизации (СТОК), ко- 
торая будет рассмотрена ниже, широковещательный адрес этого типа такой же, как 
и адрес вещания на сеть; КЕС 1812 предлагает трактовать их одинаково. 


Вещание на все подсети 


В адресе для вещания на все подсети задан идентификатор сети, а адреса под- 
сети и хоста состоят из одних единиц. Как и при вещании на подсеть, для опозна- 
ния такого адреса необходимо знать маску подсети. 

К сожалению, применение адреса для вещания на все подсети сопряжено с не- 
которыми проблемами, поэтому этот режим не внедрен. При использовании 
СТОК этот вид широковещания не нужен и, по ВЕС 1812, «отправлен на свал- 
ку истории». 


Бесклассовая междоменная маршрутизация [000 РС 


Ни один из описанных широковещательных адресов нельзя использовать 
в качестве адреса источника 1Р-датаграммы. И, наконец, следует отметить, что 
в некоторых ранних реализациях ТСР/]ТР, например в системе 4.2В$0, для выде- 
ления широковещательного адреса в поле идентификатора хоста ставились нееди- 
НИЦЫ, а нули. 


Бесклассовая междоменная маршрутизация - СОК 


Теперь вам известно, как организация подсетей решает одну из проблем, свя- 
занных с классами адресов: переполнение маршрутных таблиц. Хотя и в мень- 
шей степени, подсети все же позволяют справиться и с проблемой истощения 
]Р-адресов за счет лучшего использования пула идентификаторов хостов в пре- 
делах одной сети. 

Еще одна серьезная проблема -— это недостаток сетей класса В. Как показано 
нарис. 2.5, существует менее 17000 таких сетей. Поскольку большинство средних 
и крупных организаций нуждается в количестве 1Р-адресов, превышающем воз- 
можности сети класса С, им выделяется идентификатор сети класса В. 

В условиях дефицита сетей класса В организациям приходилось выделять бло- 
ки адресов сетей класса С, но при этом вновь возникает проблема, которую пыта- 
лись решить с помощью подсетей, — растут маршрутные таблицы. 

Бесклассовая междоменная маршрутизация (СТОК) решает эту проблему, вы- 
вернув принцип организации подсетей «наизнанку». Вместо увеличения СШВ 
уменьшает длину идентификатора сети в 1Р-адресе. 

Предположим, некоторой организации нужно 1000 ТР-адресов. Ей выделяют 
четыре соседних идентификатора сетей класса С с общим префиксом от 200.10.4.0 
до 200.10.7.0. Первые 22 бита этих идентификаторов одинаковы и представляют 
номер агрегированной сети, в данном случае 200.10.4.0. Как и для подсетей, для 
идентификации сетевой части [Р-адреса используется маска сети. В приведенном 
здесь примере она равна 255.255.252.0 (0х с00). 

Но вотличие от подсетей эта маска сети не расширяет сетевую часть адреса, а уко- 
рачивает ее. Поэтому СТОК называют также суперсетями. Кроме того, маска сети 
в отличие от маски подсети экспортируется во внешний мир. Она становится час- 
тью любой записи маршрутной таблицы, ссылающейся на данную сеть. 

Допустим, внешнему маршрутизатору В надо переправить датаграмму по ад- 
ресу 200.10.5.33, который принадлежит одному из хостов в агрегированной сети. 
Он просматривает записи в своей маршрутной таблице, в каждой из которых хра- 
нится маска сети, и сравнивает замаскированную часть адреса 200.10.5.33 с храня- 
щимся в записи значением. Если в таблице есть запись для сети, то в ней будет 
храниться адрес 200.10.4.0 и маска сети 255.255.252.0. Когда выполняется опера- 
ция побитового АХО между адресом 200.10.5.33 и этой маской, получается значе- 
ние 200.10.4.0. Это значение совпадает с хранящимся в записи номером подсети, 
так что маршрутизатору известно, что именно по этому адресу следует перепра- 
вить датаграмму. 

Если возникает неоднозначность, то берется самое длинное соответствие. 
Например, в маршрутной таблице может быть также запись с адресом 200.10.0.0 
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и маской сети 255.255.0.0. Эта запись также соответствует адресу 200.10.5.33, но 
поскольку для нее совпадают только 16 бит, а не 22, как в первом случае, то пред- 
почтение отдается первой записи. 


Прамечание Может случиться так, что риетеё сервис-провайдер (15Р) «вла- 
деет» всеми [Р-адресами с префиксом 200.10. В соответствии со 
второй из рассмотренных выше записей маршрутизатор отпра- 
вил бы этому провайдеру все датаграммы, адрес назначения ко- 
торых начинается с 200.10. Тогда провайдер смог бы указать 
более точный маршрут, чтобы избежать лишних звеньев в мар- 
шруте или по какой-то иной причине. 


В действительности механизм СТОЕК более общий. Он называется «бесклассо- 
вым», так как понятие «класса» в нем полностью отсутствует. Таким образом, каж- 
дая запись в маршрутной таблице содержит маску сети, определяющую сетевую 
часть [Р-адреса. Если принять, что адрес принадлежит некоторому классу, то эта 
маска может укоротить или удлинить сетевую часть адреса. Но поскольку в СТОВ 
ПОНЯТИЯ «класса» нет, то можно считать, что сетевая маска выделяет сетевую часть 
адреса без изменения ее длины. 

В действительности, маска - это всего лишь число, называемое префиксом, ко- 
торое определяет число бит в сетевой части адреса. Например, для вышеупомяну- 
той агрегированной сети префикс равен 22, и адрес этой сети следовало бы записать 
как 200.10.4.0/22, где /22 обозначает префикс. С этой точки зрения адресацию на 
основе классов можно считать частным случаем СТОВ, когда имеется всего четыре 
(или пять) возможных префиксов, закодированных в старших битах адреса. 

Гибкость, с которой СТОК позволяет задавать размер адреса сети, позволяет 
эффективно распределять [Р-адреса блоками, размер которых оптимально соот- 
ветствует потребностям сети. Вы уже видели, как можно использовать СТОК для 
агрегирования нескольких сетей класса С в одну большую сеть. А для организа- 
ции маленькой сети из нескольких хостов можно выделить лишь часть адресов 
сети класса С. Например, сервис-провайдер выделяет небольшой компании с един- 
ственной ЛВС адрес сети 200.50.17.128/26. В такой сети может существовать до 
62 хостов (28-2). 

В ВЕС 1518 [Кек\ег и 4 1993] при обсуждении вопроса об агрегировании 
адресов и его влиянии на размер маршрутных таблиц рекомендуется выделять 
префиксы ГР-адресов (то есть сетевые части адреса) иерархически. 


Прамечание Иерархическое агрегирование адресов можно сравнить с иерар- 
хической файловой системой вроде тех, что используются 
в ОМХ и Утао5. Так же, как каталог верхнего уровня содер- 
жит информацию о своих подкаталогах, но не имеет сведений 
о находящихся в них файлах, доменам маршрутизации верхнего 
уровня известно лишь о промежуточных доменах, а не о конк- 
ретных сетях внутри них. Предположим, что региональный 
провайдер обеспечивает весь трафик для префикса 200/8, 
а к нему подключены три локальных провайдера с префиксами 
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200.1/16, 200.2/16 и 200.3/16. У каждого провайдера есть несколько 
клиентов, которым выделены части располагаемого адресного 
пространства (200.1.5/24 и т.д.). Маршрутизаторы, внешние по 
отношению к региональному провайдеру, должны хранить 
в своих таблицах только одну запись - 200/8. Этого достаточ- 
но для достижения любого хоста в данном диапазоне адресов. 
Решения о выборе маршрута можно принимать, даже не зная 
о разбиении адресного пространства 200/8. Маршрутизатор 
регионального провайдера должен хранить в своей таблице 
только три записи: по одной для каждого локального провай- 
дера. На самом нижнем уровне локальный провайдер хранит 
записи для каждого своего клиента. Этот простой пример 
позволяет видеть суть агрегирования. 


Почитать ВЕС 1518 очень полезно, поскольку в этом документе демонстриру- 
ются преимущества использования СТОК. В ВЕС 1519 [Ещег её а1. 1993] описаны 
СТОК иее логическое обоснование, а также приведены подробный анализ затрат, свя- 
занных с СТОК, и некоторые изменения, которые придется внести в протоколы меж- 
доменной маршрутизации. 


Текущее состояние организации подсетей и СОВ 


Подсети в том виде, в каком они описаны в ВЕС 950 [Мовчц] ап4 Розе] 1985], — 
это часть Стандартного протокола (514. 5). Это означает, что каждый хост, на ко- 
тором установлен стек ТСР/ТР, обязан поддерживать подсети. 

СТВ (ВЕС 1517 [Нишдеп 1993], ВЕС 1518, ВЕС 1519) - часть предложений 
к стандартному протоколу, и потому не является обязательной. Тем не менее СТОК 
применяется в [Пщегпеё почти повсеместно, и все новые адреса выделяются этим 
способом. Группа по перспективным разработкам в пщегпеё (1Е$ С — Пщегпеё Еп1- 
пеенпз Збеегшя Стоир) выбрала СТОВ, как промежуточное временное решение 
проблемы роста маршрутных таблиц. 

В перспективе обе проблемы — исчерпания адресов и роста маршрутных таб- 
лиц — предполагается решать с помощью версии 6 протокола 12. ТРуб имеет боль- 
шее адресное пространство (128 бит) и изначально поддерживает иерархию. Та- 
кое адресное пространство (включая 64 бита для идентификатора интерфейса) 
гарантирует, что вскоре 1Р-адресов будет достаточно. Иерархия 1Руб-адресов по- 
зволяет держать размер маршрутных таблиц в разумных пределах. 


Резюме 


В этом разделе рассмотрены подсети и бесклассовая междоменная маршрути- 
зация (СТОК). Вы узнали, как они применяются для решения двух проблем, свой- 
ственных адресации на основе классов. Подсети позволяют предотвратить рост 
маршрутных таблиц, обеспечивая в то же время гибкую адресацию. СТОВ служит 
для эффективного выделения 1Р-адресов и способствует их иерархическому на- 
значению. 
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Совет 3. Разберитесь, что такое частные адреса и МАТ 


Раньше, когда доступ в Пиегпеё еще не был повсеместно распространен, орга- 
низации выбирали произвольный блок [Р-адресов для своих сетей. Считалось, что 
сеть не подключена и «никогда не будет подключена» к внешним сетям, поэтому 
выбор [Р-адресов не имеет значения. Но жизнь не стоит на месте, и в настоящее 
время очень мало сетей, которые не имеют выхода в Пиегпе. 

Теперь необязательно выбирать для частной сети произвольный блок [Р-адре- 
сов. В ВЕС 1918 [Ве Мег, МозКо\2 её а1. 1996] специфицированы три блока ад- 
ресов, которые не будут выделяться: 


о 10.0.0.0-10.255.255.255 (префикс 10/8); 
о 172.16.0.0-172.31.255.255 (префикс 172.16/12); 
о 192.168.0.0—192.168.255.255 (префикс 192.168/16). 


Если использовать для своей сети один из этих блоков, то любой хост сможет 
обратиться к другому хосту в этой же сети, не опасаясь конфликта с глобально 
выделенным [Р-адресом. Разумеется, пока сеть не имеет выхода во внешние сети, 
выбор адресов не имеет значения. Но почему бы сразу не воспользоваться одним 
из блоков частных адресов и не застраховаться тем самым от неприятностей, кото- 
рые могут произойти, когда внешний выход все-таки появится? 

Что случится, когда сеть получит внешний выход? Как хост с частным [Р-ад- 
ресом сможет общаться с другим хостом в Пкцегпе или другой внешней сети? Са- 
мый распространенный ответ — нужно воспользоваться преобразованием сетевых 
адресов (Мегуотк АЧ@гез$ Тгап$|айопт — МАТ). Есть несколько типов устройств, 
поддерживающих МАТ. Среди них маршрутизаторы, межсетевые экраны (Йге\а|5) 
и автономные устройства с поддержкой МАТ. Принцип работы МАТ заключается 
в преобразовании между частными сетевыми адресами и одним или несколькими 
глобально выделенными 1Р-адресами. Большинство устройств с поддержкой МАТ 
можно сконфигурировать в трех режимах: 


С статический. Адреса всех или некоторых хостов в частной сети отображают- 
ся на один и тот же фиксированный, глобально выделенный адрес; 

о выбор из пула. Устройство с поддержкой МАТ имеет пул глобально выделен- 
ных [Р-адресов и динамически назначает один из них хосту, которому нуж- 
но связаться с хостом во внешней сети; 

о РАТ, или преобразование адресов портов (рог а4@гезз (гапз!а оп). Этот ме- 
тод применяется, когда есть единственный глобально выделенный адрес 
(рис. 2.11). При этом каждый частный адрес отображается на один и тот же 
внешний адрес, но номер порта исходящего пакета заменяется уникальным 
значением, которое в дальнейшем используется для ассоциирования входя- 
щих пакетов с частным сетевым адресом. 


На рис. 2.11 представлена небольшая сеть с тремя хостами, для которой ис- 
пользуется блок адресов 10/8. Имеется также маршрутизатор, помеченный МАТ, 
у которого есть адрес в частной сети и адрес в Пиегпей. 


Частные адреса и МАТ 


В шете 


205.184.151.171 


Епете! 


Рис. 2.11 
Частная сеть с маршрутизатором, 
10.0.0.1 10.0.0.2 10.0.0.3 который поддерживает МАТ 


Поскольку показан только один глобальный адрес, ассоциированный с МАТ, 
предположим, что маршрутизатор сконфигурирован с возможностью использо- 
вания метода РАТ. Статический режим и режим выбора из пула аналогичны мето- 
ду РАТ, но проще его, поскольку не нужно преобразовывать еще и номера портов. 

Допустим, что хосту Н2 надо отправить $УМ-сегмент ТСР поадресу 204.71.200.69 — 
на один из \еЬ-серверов ммлмуаоо.сот, — чтобы открыть соединение. На рис. 2.12а 
видно, что у сегмента, покидающего Н2, адрес получателя равен 204.71.200.69.80, 
а адрес отправителя - 10.0.0.2.9600. 


Примечание Здесь использована стандартная нотация, согласно которой 


адрес, записанный в форме А.В.С.О.Р означает 1[Р-адрес 
А.В.С.О и порт Р. 


В этом нет ничего особенного, за исключением того, что адрес отправителя 
принадлежит частной сети. Когда этот сегмент доходит до маршрутизатора, МАТ 
должен заменить адрес отправителя на 205.184.151.171, чтобы УМеБ-сервер на сай- 
те УаВоо знал, куда посылать сегмент ЗУМ/АСК и последующие. Поскольку во 
всех пакетах, исходящих от других хостов в частной сети, адрес отправителя так- 
же будет заменен на 205.184.151.171, МАТ необходимо изменить еще и номер пор- 
Та на некоторое уникальное значение, чтобы потом определять, какому хосту сле- 
дует переправлять входящие пакеты. Исходящий порт 9600 преобразуется в 5555. 
Таким образом, у сегмента, доставленного на сайт УаВоо, адрес получателя будет 
204.71.200.69.80, а адрес отправителя - 205.184.151.171.5555. 


$ = 10.0.0.2.9600 $ = 205 184.151.171.5555 


О = 204.71.200.69.80 О =204.71.200.69.80 


$ = 204.71.200.69.80 
О = 10.0.0.2.9600 


$ = 204.71.200.69.80 
О = 205.184.151.171.5555 


[= 


Рис. 2.12. Преобразование адресов портов 


Основы 


Из рис. 2.126 видно также, что в дошедшем до маршрутизатора ответе Уавоо 
адрес получателя равен 205.184.151.171.5555. МАТ ищет этот номер порта в сво- 
ей внутренней таблице и обнаруживает, что порт 5555 соответствует адресу 
10.0.0.1.9600, так что после получения от маршрутизатора этого пакета в хосте На 
появится информация, что адрес отправителя равен 204.71.200.69.80, а адрес по- 
лучателя - 10.0.0.1.9600. 

Описанный здесь метод РАТ выглядит довольно примитивно, но есть много 
усложняющих его деталей. Например, при изменении адреса отправителя или но- 
мера исходящего порта меняются как контрольная сумма заголовка 1Р-датаграммы, 
так и контрольная сумма ТСР-сегмента, поэтому их необходимо скорректировать. 

В качестве другого примера возможных осложнений рассмотрим протокол пе- 
редачи файлов ЕТР (Ее Тгапзег Ргобосо|) [Кеупо]4$ ап4 Розе! 1985]. Когда ЕТР- 
клиенту нужно отправить файл или принять его от ЕТР-сервера, серверу посылает- 
ся команда РОКТ с указанием адреса и номера порта, по которому будет ожидаться 
соединение (для передачи данных) от сервера. При этом МАТ нужно распознать 
ТСР-сегмент, содержащий команду РОКТ протокола ЕТР, и подменить в ней ад- 
рес и порт. В команде РОКТ адрес и номер порта представлены в виде АЗСП- 
строк, поэтому при их подмене может измениться размер сегмента. А это, в свою 
очередь, повлечет изменение порядковых номеров байтов. Так что МАТ должен за 
этим следить, чтобы вовремя скорректировать порядковые номера в сегменте под- 
тверждения АСК, а также в последующих сегментах с того же хоста. 

Несмотря на все эти сложности, МАТ работает неплохо и широко распространен. 
В частности, РАТ - это естественный способ подключения небольших сетей к [тцегпей 
в ситуации, когда имеется только одна точка выхода. 


Резюме 


В этом разделе показано, как схема МАТ позволяет использовать один из бло- 
ков частпых сетевых адресов для внутренних хостов, сохраняя при этом возмож- 
ность выхода в Ицегпеб. Метод РАТ, в частности, особенно полезен для небольших 
сетей, у которых есть только один глобально выделенный [Р-адрес. К сожалению, 
поскольку РАТ изменяет номер порта в исходящих пакетах, он может оказаться 
несовмесгимым с нестандартными протоколами, которые передают информацию 
о номерах портов в теле сообщения. 


Совет 4. Разрабатывайте и применяйте 
каркасы приложений 


Большинство приложений ТСР/Р попадают в одну из четырех категорий: 


о ТСР-сервер; 
о ТСР-клиент; 
о О,Р-сервер; 
о ОО,Р-клиент. 
В приложениях одной категории обычно встречается почти одинаковый «стар- 


товый» код, который инициализирует все, что связано с сетью. Например, ТСР- 
сервер должен поместить в поля структуры зоскаааг_ 1п адрес и порт получателя, 


Каркасы приложений ИИ ИЕ 


получить от системы сокет типа ЗОСК_$ТВЕАМ, привязать к нему выбранный ад- 
рес и номер порта, установить опцию сокета 50_ВЕЧЗЕАРОВ (совет 23), вызвать 
11з6 еп, а затем быть готовым к приему соединения (или нескольких соединений) 
с помощью системного вызова ассере. 

На каждом из этих этапов следует проверять код возврата. А часть програм- 
мы, занимающаяся преобразованием адресов, должна иметь дело как с число- 
выми, так и с символическими адресами и номерами портов. Таким образом, 
в любом ТСР-сервере есть порядка 100 почти одинаковых строк кода для вы- 
полнения всех перечисленных выше задач. Один из способов решения этой про- 
блемы - поместить стартовый код в одну или несколько библиотечных функ- 
ций, которые приложение может вызвать. Эта стратегия использована в книге. 
Но иногда приложению нужна слегка видоизмененная последовательность ини- 
циализации. В таком случае придется либо написать ее с нуля, либо извлечь 
нужный фрагмент кода из библиотеки и подправить его. 

Чтобы справиться и с такими ситуациями, можно построить каркас приложе- 
ния, в котором уже есть весь необходимый код. Затем скопировать этот каркас, 
внести необходимые изменения, после чего заняться логикой самого приложения. 
Не имея каркаса, легко поддаться искушению и срезать некоторые углы, напри- 
мер, жестко «зашить» в приложение адреса (совет 29) или сделать еще что-то со- 
мнительное. Разработав каркас, вы сможете убрать все типичные функции в би- 
блиотеку, а каркас оставить только для необычных задач. 

Чтобы сделать программы переносимыми, следует определить несколько мак- 
росов, в которых скрыть различия между АР] систем МХ и УЙпдо\з. Например, 
в ОМХ системный вызов для закрытия сокета называется с1озе, а в \УЯп4о\'з — 
с1озевоскее. Версии этих макросов для ОМХ показаны в листинге 2.1. Версии 
для \Пп4о\!з аналогичны, приведены в приложении 2. Доступ к этим макросам из 
каркасов осуществляется путем включения файла зКе! . |. 


Листинг 2.1. Заголовочный файл зКе!.Н 


эзке!1. п 
1 #1ЕпаеЕ _ $УКЕЦШН__ 
2 #аеЕ1те  УКЕГ_Н__ 
3 /* версия для ОХ */ 
4 #АеЕ1те ТМТТ() ( ргодгап_паме = \ 
5 зЕкксИЕ( акау[ 0], '/') ) ? \ 
6 ргоагат_пате++ : \ 
7 ( ргоагам_паше = агаУу[ 0 |] ) 
8 #аеЕ1те ЕХТТ(5) ех1е (3) 
9 #аеЁЕ1пе СЬО$Е(з) 1Е ( с1озе( з } }) еккок( 1, ехктпо, \ 
10 "ошибка с1озе " ) 
11 #аеЕ1те зее_еггпо(е) еггпо = (е } 
12 #АеЕ1тпе 1зуа11@зосК ($) ((8°) >=0) 


13 суреаеЕЁ 1пЕ 5ОСКЕТ; 


14 #епатЕ /* __5КЕБ_Н_ */ 
ке]. 5 
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Начнем с каркаса ТСР-сервера. Затем можно приступить к созданию библио- 
теки, поместив в нее фрагменты кода из каркаса. В листинге 2.2 показана функция 


па1п. 


Листинг 2.2. функция тат из каркаса 1срзегуег.5Ке! 


оючмиююь- 


‘о 


нь нь на 
шв о 


-? 
> 


хмм ююввнвнвы 
шьвоюочамп 


о) 
&л 


шшшыш,ышьюьююъ 
яоыюноюоючтм 


шшо.шоъо 
о юм 


#1пс1аае 
#1пс1аае 
#1пс1аае 
#1пс1аае 
#1пс1аае 
#1пс1аае 
#1пс1аае 
#10с1аае 
#1пс11аае 
#1пс1аае 
#1пс1аае 
#1пс1аае 
#10с1цае 


<зЕА1о.Н> 
<86а11Ь.Н> 
<ип186а.Н> 
<5ЕЧага.Н> 
<8Ег1п9.[> 
<еггпо.|> 
<пеёаь.в> 
<Еспё1.6> 
<зуз/Е1тме.Н> 
<зув/зоскее. [> 
<пеё1пее/1п.[Н> 
<агра/1пеё.п> 
"зке1.Ц" 


сваг *ргодгащ_пате; 


10Е па1п( 116 акгсдс, 


{ 


зЕгисЕ воскааак_1п 1оса1; 
зЕкгисЕе воскаааг_1п реег; 


саг *Шпаше; 

саг *впаше; 

1пЕ реег1еп; 
бОСКЕТ $1; 

ЗОСКЕТ в; 

сопвЕ 106 оп = 1; 


ТМТТ(); 


1Е ( акас == 2 ) 


{ 


ВБраме 
зпаме 


} 


е1<зе 


{ 


МОЕ; 
агау[ 1 ]; 


И 


Праше = акау[ 1 ]; 
зпаме = агау[ 2 ]; 


} 


зее_аЯЯхезз( Бпаме, 
$ = зоскее( АЕ_ТМЕТ, $0ОСК_5УТВЕАМ, 
!11зуа11@авоск ( 
еггог( 1, егхпо, "ошибка вызова зоскеб" 


ЗЕ ( 


| 


спаг **акау ) 


зпапе, 


5 ) 
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Есрзегуег, ке] 
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40 
41 
42 


43 
44 
45 


46 
47 
48 
49 
50 
5 
52 
53 
54 
55 
56 
57 
58} 


1Е ( зебзосКоре( зв, 50. _ЗОСКЕТ, $0_ВЕОЗЕАООКВ, &оп, 
312е0Ё( оп ) ) ) 
егхог( 1, ехгхгпо, "ошибка вызова зеЕзосКоре" ); 


1Е ( Б1та( з, ( зЕхоасб зосКаа@аг * ) &1оса1, 
$12ео0Ё( 1оса1 ) } ) 
егхог( 1, екхгпо, "ошибка вызова Б1та" ); 


1Е ( 113з6еп( ®, МЬЫТУТЕМ ) ) 
еггог( 1, еггпо, "ошибка вызова 113з6еп" ); 
ао 


реех1еп = 517еоЁ( реег ); 
$1 = ассерЕ( з, ( зЕкасЕ зоска@Яхг * )&реег, &реег]1еп )}; 
1Е ( !13уа11ЯзосК( э1 ) ) 
егхгог( 1, ехгхгпо, "ошибка вызова ассере" ); 
зегуег( 31, &реег )}; 


СЬО$Е( э1 ); 
} мр11е (1); 
ЕХТТ (О); 


Есрзегуег. эКе]1 


Включаемые файлы и глобальные переменные 


1-14 


25 


Включаем заголовочные файлы, содержащие объявления используе- 
мых стандартных функций. 

Макрос ТМТТ выполняет стандартную инициализацию, в частности, 
установку глобальной переменной ргодгат_паме для функции еггог 
и вызов функции ИЗАЗЕагеир при работе на платформе УЛп4о\з. 


Функция тат 


26-35 


36 


37-45 


46-47 


48-56 


Предполагается, что при вызове сервера ему будут переданы адрес и но- 
мер порта или только номер порта. Если адрес не указан, то привязыва- 
ем к сокету псевдоадрес ТМАРОК_АМУ, разрешающий прием соединений 
по любому сетевому интерфейсу. В настоящем приложении в командной 
строке могут, конечно, быть и другие аргументы, обрабатывать их надо 
именно в этом месте. 

Функция зе _аЯЯгезз записывает в поля переменной 1оса1 типа 
зосКкаааг _1п указанные адрес и номер порта. Функция зеё_аЯагез 
показана в листинге 2.3. 

Получаем сокет, устанавливаем в нем опцию 50_ВЕОЗЕАОРК (совет 23) 
и привязываем к нему хранящиеся в переменной 1оса1 адрес и номер 
порта. 

Вызываем 11э6еп, чтобы сообщить ядру о готовности принимать со- 
единения от клиентов. 

Принимаем соединения и для каждого из них вызываем функцию 
зегуег. Она может самостоятельно обслужить соединение или создать 
для этого новый процесс. В любом случае после возврата из функции 
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зегуег соединение закрывается. Странная, на первый взгляд, конст- 
рукция ао-иН11е позволяет легко изменить код сервера так, чтобы он 
завершался после обслуживания первого соединения. Для этого доста- 
точно вместо 


\131е (1); 
написать 
мр1]е (0); 


Далее обратимся к функции зе _а@9гезз. Она будет использована во всех 
каркасах. Это естественная кандидатура на помещение в библиотеку стандартных 


функций. 


Листинг 2.3. Функция зеЁ аа ге$$ 


{ 


2 
2 
Е 
4 
5 
6 
Е. 
8 


Есрзегуег. ке] 


згае1с \у01Я зеЕ_ааахгезз( срахг *рпаше, срахг *зпапе, 


зЕкисЕ зосКаааг_1п *вар, сваг *ргобосо] } 


зЕкисЕ зекуепбе *вр; 
зЕкисЕе Позбепйе *Бр; 
сраг *епарег; 

зрохгЕ рогё; 


Рхего( зар, $12ео0Е( *зар ) ); 
зар->$1п_Ёат11у = АЕ_ТМЕТ; 
1Е ( Ппате != МОШ ) 
{ 
1Е ( !1пеб_абоп( Рраме, &зар->$1п_ааахг ) ) 
{ 
Пр = десвозеБупаме( Ппапше ); 
ТЕ (ВР == Ш ) 
еггохг( 1, 0, "неизвестный хост: %5\п", Бпаще ); 
зар->51п_а@ак = *( зекгасЕ 1п_ааахг * )Нр->В_ааак; 
| 
} 


е]1 зе 
зар->$1п_аааг.в_а@а" = Пбоп]1 ( ТМАРОВ_АМУ )}; 
рогЕ = $з6хЕ0о]1( зпаме, &епарег, 0 }; 
1Е ( *епарех == '\0' } 
зар->$1п_рохЕ = РБЕоп$( рок ); 
е]1 зе 


{ 
зр = чеЕзегубурпате( зпаше, ргоеосо1 ); 
1Е (эр == Ш ) 
еггог( 1, 0, "неизвестный сервис: %5\п", спаше }; 
зар->51п_рогЕ = эр->$8_рогё; 


Есрзегуег. ке] 
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8-9 Обнулив структуру зосКааак_1п, записываем в поле адресного семей- 
ства АЕ_ТМЕТ. 

10-19 Если Бпате не МОШ,, то предполагаем, что это числовой адрес в стан- 
дартной десятичной нотации. Преобразовываем его с помощью функ- 
ции 1пее_акоп, если 1пеб_абоп возвращает код ошибки, — пытаемся 
преобразовать Враше в адрес с помощью деепозЕЪупапе. Если и это 
не получается, то печатаем диагностическое сообщение и завершаем 
программу. 

20-21 Если вызывающая программа не указала ни имени, ни адреса хоста, 
устанавливаем адрес ТМАРОК_АМУ. 

22-24 Преобразовываем зпате в Целое число. Если это удалось, то записы- 
ваем номер порта в сетевом порядке (совет 28). 

27-30 В противном случае предполагаем, что это символическое название 
сервиса и вызываем де зекуьупаме для получения соответствующе- 
го номера порта. Если сервис неизвестен, печатаем диагностическое со- 
общение и завершаем программу. Заметьте, что деёзехуБупаще уже 
возвращает номер порта в сетевом порядке. 


Поскольку иногда приходится вызывать функцию зе _а@9гезз напрямую, 
здесь приводится ее прототип: 


велаае "ево > т 


| \014 зе _ааагезз( спаг *Но5Е, саг *ротёЕ, | 
зЕгисЕ зоскаааг_1п *5ар, спаг *ргоЕосо]1 )}; 


ыы амаль Е НЕ ИНН -| 


Последняя функция - еггог - показана в листинге 2.4. Это стандартная диа- 
гностическая процедура. 


ВНЕ РАНЧО РАНА НИР НЕВЕ ООВ ОНИКС ЗЕЕ ЗЕЕ НИЕ ЗЕ НЕЕ - 


#10с1иае "ебср.п" 


Если этатиз не равно 0, то еггог завершает программу после печати диагнос- 
тического сообщения; в противном случае она возвращает управление. Если егг 
не равно 0, то считается, что это значение системной переменной еггпо. При этом 
в конец сообщения дописывается соответствующая этому значению строка и чис- 
ловое значение кода ошибки. 

Далее в примерах постоянно используется функция екгог, поэтому добавим 
ее в библиотеку. 


Листинг 2.4. Функция етог 


Есрзегуег. зКе1 
1 уо1а екгког( 1пЕ збабаз, 1пЕ егк, саг *Еше, ... ) 

2 { 

3 уа_11$5е ар; 


56 1 РЕ Основы 


4 уа_збахе( ар, ЕшЕ )}; 

5 Ерх1пЕЕ( зЕЧегхг, "%з: ", ргоадгап_пашме )}; 
6 УЕрг1пЕЕ( зЕЧехгг, Ее, ар }; 

7 уа_еп@( ар ); 

8 


1Е ( ехк } 
9 Ерх1пЕЁ( вЕаегхи, "; %5 (%9)\п", зехеггох( ехкхг ), ехг ); 
10 1Е ( зкабаз ) 
11 ЕХТТ( зеабоз ); 
12 } 


Е срзегуег . зКе1. 
В каркас включена также заглушка для функции зегуег: 


зсаё1с \о1@ зегуег (ЗОСКЕТ 3, зЕехасЕ зоскаааг_1п *реегр } 
{ 
} 


Каркас можно превратить в простое приложение, добавив код внутрь этой за- 
глушки. Например, если скопировать файл Есрзегуег. ке] в Ве11о.с и заме- 
нить заглушку кодом 


збае1с \уо1@Я зекуехт (5ОСКЕТ з, зЕкисЕ зоска@ахг_1п *реехгр } 
{ 

зепа( $3, "Ре11о, мог1а\п", 13, 0); 
} 


то получим сетевую версию известной программы на языке С. Если откомпилиро- 
вать и запустить эту программу, а затем подсоединиться к ней с помощью програм- 
мы бешпе*, то получится вполне ожидаемый результат: 


рза: $ Ъе11о 9000 

[1] 1163 

Ьза: $ Ее1пеЕ 1оса]1ВовЕ 9000 
Тгузпа 127.0.0.1... 

СоппесЕеЯ со 1оса1фозё 

Езсаре спагхасеег '^]'. 

Ве11о, мог1а 

Соппесё1оп с1озеа Бу Ёогке1ап Нозе. 


Поскольку каркас Есрзегуег . зКе1 описывает типичную для ТСР-сервера си- 
туацию, поместим большую часть кода та {п в библиотечную функцию Еср_зегуек, 
показанную в листинге 2.5. Ее прототип выглядит следующим образом: 


#1пс14ае "еёср.В" 


| СОСКЕТ Еср_зегуег( спаг *НозёЁ, спахг *рокЕ ); 
| Возвращаемое значение: сокет в режиме прослушивания (в случае ошибки 3а-| 
вершает программу). 

Параметр ВозЕ указывает на строку, которая содержит либо имя, либо ТР-ад- 
рес хоста, а параметр рогЕ - на строку с символическим именем сервиса или но- 
мером порта, записанным в виде АЗСП-строки. 
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Далее будем пользоваться функцией Е ср_зегуег, если не возникнет необхо- 
димость модифицировать каркас кода. 


Листинг 2.5. Функция {1ср_5егуег 


Гср_зегуег.с 


1 ЗОСКЕТ Еср_вегуег( сраг *Кпаще, сПаг *зпапще ) 

2 { 

3 зЕКГИСЕ зоскКаЯЯг_1п 1оса1; 

4 ЗОСКЕТ 3; 

5 сопзЕ 116 оп = 1; 

6 зеё_аЯЧгезз( рпаме, зпаще, &1оса1, "Еср" ); 

7 3 = взосКее( АЕ ТМЕТ, $ОСК_УТВЕАМ, 0); 

8 1Е ( !13уа11Яазоск( в ) } 

9 егхгог( 1, еггпо, "ошибка вызова зосКкее" }; 
10 1Е ( зебзоскоре( в, $0._бОСКЕТ, $0_ВЕОЗЕАООВ, 
11 ( СВак * )&оп, з17еоЁ( оп } ) ) 

12 еггог( 1, еггпо, "ошибка вызова зеезосКоре" }; 
13 1Е ( Ь1па( в, ( зЕкгасЕ звосКа@ааг * ) &1оса1, 
14 $17е0Ё( 1оса1 } } ) 
15 еггог( 1, еггпо, “ошибка вызова Ю1па" }; 
16 1Е { 11з6еп( з, МЫТУТЕМ ) ) 
17 еггог( 1, еггпо, "ошибка вызова 1156еп" )}; 
18 гебогп з; 
19 } 
Еср_зегуег.с 
Каркас ТСР-клиента 


Рассмотрим каркас приложения ТСР-клиента (листинг 2.6). Если не считать 
функции па1п и замены заглушки зегуег заглушкой с11еп, то код такой же, как 
для каркаса 'ТСР-сервера. 


Листинг 2.6. Функция тат из каркаса {срс!епЕ $Ке! 


{ 


и 
2 
3 
4 
5 
6 
7 
8 
9 
0 
ь 


Есрс]1епЕ.зке1 


116 па1п( 116 агдс, сваг **акдау ) 


зЕгасЕ зосКаЯаг_1п реег; 
ЗОСКЕТ в; 


ТМТТ(); 
зее_аЯагезв( агау[ 1 ], агау[ 2 }, &реех, "бер" ); 


8 = зосКеЕе( АЕ_ТМЕТ, 5ОСК_5ТВЕАМ, 0 ); 


1Е ( 1!15уа11ЯазосКк( в }) ) 
еггох( 1, еггпо, "ошибка вызова зоскКее" }; 
1Е ( соплес®( 3, ( зегисбЕ взоска@аЯг * )бреехк, 


312е0оЁ( реег ) ) ) 
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12 еггог( 1, еггпо, "ошибка вызова соппесёе" ); 
13 с11епе ( 3, &реег }; 
14 ЕХТТ( О }; 
15 } 


Есрс11епё.5зКе]1 


{кр_сЙепт.5Ке! 

6-9 Как и в случае есрзекуех. зКе1, записываем в поля структуры 
зоскаЯахк _1п указанные адрес и номер порта, после чего получаем сокет. 

10-11 Вызываем соппес® для установления соединения с сервером. 

13 После успешного возврата из соппес® вызываем заглушку с11еп, пе- 
редавая ей соединенный сокет и структуру с адресом сервера. 


Протестировать клиент можно, скопировав каркас в файл Ве11ос.с и дописав 
в заглушку следующий код: 


эсае1с \уо1А с11епе( ЗОСКЕТ 5, зегасе зоскаа9г_1п *реехгр ) 
{ 


106 гс; 
саг БаЁ|[ 120 ]; 


ое о 
{ 
гс = гесу( 5, БаЕЁ, $12еоЁ( БаЁ }), 0); 
тЁ ((. Ее == 20. } 
ЬгеаК; 
муг1ее( 1, БЕ, тс }; 


} 


Этот клиент читает из сокета данные и выводит их на стандартный вывод 
до тех пор, пока сервер не пошлет конец файла (ЕОР). Подсоединившись 
к серверу Ве11о, получаете: 


Ьза: $ Ве11о 1оса1Вов® 9000 
Ве11о, мог1а 
Ьза: $ 


Поместим фрагменты кода Есрс11епе.зКе1 в библиотеку, так же, как посту- 
пили с каркасом Есрс11епё.зКке1. Новая функция -— Еср_с11епё, приведенная 
в листинге 2.7, имеет следующий прототип: 


#1пс]аЯе "ебср.П" 
| ЗОСКЕТ Еср_с11епё( срахг *НозЕ, спаг *рогЕё ); 


| Возвращаемое значение: соединенный сокет (в случае ошибки завершает про-| 
грамму). 


С — ыы > == == === ыы =>=Г > =ы ==ы = риа снннеы — пишиыиык — чаааащыи — ПаБиеныь  Бмаеннен — сиаааии я ББИыые — ПЕНЬ я свиаарии — пиииинии ЕЕ ВЕНЕ 


Как и в случае (ср_вегуег, параметр БозЕ содержит либо имя, либо ГР-адрес 
хоста, а параметр рогЕё — символическое имя сервиса или номер порта В виде 
А$СП-строки. 


Каркасы приложений 


Листинг 2.7. Функция кр_спет 


м фср с11ептё.с 
СОСКЕТ Еср_с11епЁ( сВаг *рпаше, срах *впапе ) 


зЕгисЕ зоскКааах_1п реек; 
ЗОСКЕТ 3; 


5 зеЕ_ ааЯагез$( Рпаме, зпаме, &реег, "Еср" ); 

6 $ = зосКкКеЕ( АЕ_ТМЕТ, $ОСК_5ТВЕАМ, 0}; 

7 1Е ( 1!13уа11азоск( в } ) 

8 етгог( 1, егхгпо, "ошибка вызова зоскее" ); 


9 1Е ( сопрпесе( $3, ( эзбгасе зоскаа@аг * )бреекг, 

10 512ео0оЁ( реег ) )} ) 

11 еггог( 1, еггро, "ошибка вызова сопрес®" }; 

12 гебогп 3; 
19 
Умер с11етё.с 
Каркас ОБР-сервера 


Каркас ООР-сервера в основном похож на каркас ТСР-сервера. Его отличи- 
тельная особенность — не нужно устанавливать опцию сокета $0_ВЕОЗЕАРОВ 
и обращаться к системным вызовам ассер* и 11зкеп, поскольку ОПТ. — это про- 
токол, не требующий логического соединения (совет 1). Функция ма1п из каркаса 
приведена в листинге 2.8. 


Листинг 2.8. Функция тат из каркаса иарзегуег.$Ке! 


цпарзегуег. ке] 


1 106 ма1зп( 116 агдс, саг **агау ) 
а { 

3 $ЕгисЕ зосКаааг_1п 1оса1; 

4 сраг *Бпрапе; 

5 сраг *зпапе; 

6 ЗОСКЕТ $; 

7 ТМТТ о); 

8 1Е ( агас == 2) 

Э { 

10 раме = мМ0Ьг; 
Та зпаме = агод\У[ 1 ]; 
8) } 

13 е1 зе 
14 { 

15 Ппаме = акоу[ 1 ]; 

16 зпатше = агау[ 2 ]; 

17 } 

18 зеё_а@Ягезз( Бпаще, зпаше, &1оса1, "зар" ); 
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19 $ = зоскКес( АЕ_ТМЕТ, $ОСК_ПОСВАМ, 0 ); 
20 1Е ( '1эуа11азосКк( ®з ) } 
21 еугог( 1, еггпо, "ошибка вызова зоскее" ); 
22 1Е ( Б1ра( 3, ( эзЕкасЕ зоскКааах * ) &1оса1, 
23 $17е0оЁ( 1оса1 ) ) ) 
24 еггог( 1, ехгхгпо, "ошибка вызова Б]лта" )}; 
25 зекуег ( $, &1оса1 ); 
26 ЕХТТ( 0); 
27 } 
парзегуег. ке] 
иарзегуег,5Ке! 
18 Вызываем функцию зе _а@9гезз для записи в поля переменной 


]оса1 типа зоскаЯаг_1п адреса и номера порта, по которому сервер 
будет принимать датаграммы. Обратите внимание, что вместо "Е ср" 
задается третьим параметром "пар". 

19-24 Получаем сокет типа $ОСК_РСКАМ и привязываем к нему адрес и номер 
порта, хранящиеся в переменной 1оса1. 

25 Вызываем заглушку зегуек, которая будет ожидать входящие датаграммы. 


Чтобы получить ЧОР-версию программы «ВеПо \’ог!4», следует скопировать 
каркас в файл ичарНе11ос .с и вместо заглушки вставить следующий код: 


$Саб1с \уо1@А зекуег( ЗОСКЕТ 3, зекасе зоска@ааг_1п *1оса1р ) 
{ 

зЕгисЕ зоскаааг_1п реег; 

106 реегк1еп; 

сваг БаЁ[ 1 |]; 


о 
{ 
реег1еп = з17еоЕЁ( реег ); 
1Е ( гесуЕхом( 8, РаЁ, $17еоЁ( БоЕЁ ), 0, 
( зсгасЕ зоскааахг * )&реег, &реег1еп ) < 0 ) 
еггог( 1, еггпо, "ошибка вызова гесуЁкош" ); 
1Е ( зепасо( в, "}№е]11о, мог19Я\п", 13, 0, 
( зЕхисе восКааЯг * }&реег, реег1епт ) < 0) 
еггог( 1, еггпо, "ошибка вызова зепасо" }; 


} 


Прежде чем тестировать этот сервер, нужно разработать каркас ЧОР-клиента 
(листинг 2.10). Но сначала нужно вынести последнюю часть па1п в библиотеч- 
ную функцию цар_зегуег: 


— = вы зы вании сывыы чвак сани шины сннлра ени саванны баны БниАо чнашаны чнышыны брани  чиашыны синие бони спанини Сонни ориии ——=—= 


#1пс1дае "ебср.В" 
ЗОСКЕТ цар_зекуек( сах *ПозЁ, спаг *рогЕ ); 


| Возвращаемое значение: ОПР-сокет, привязанный к хосту БозЕ и порту рогЕ | 
(СВ случае ошибки завершает программу). 


Е а Е ее р т ее ы 
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Как обычно, параметры Во$Е и роге указывают на строки, содержащие соот- 
ветственно имя или [Р-адрес хоста и имя сервиса либо номер порта в виде АЗСП- 
строки. 


Листинг 2.9. Функция иар_зегиег 


иар_зегуег.с 


1 5ОСКЕТ цар_вегуег( сраг *рпатме, саг *зпаше } 
2 

3 бОСКЕТ в; 

4 зЕхасЕ зоскаааг_1п 1оса]1; 

5 зеё_ааагезз$( Юпаме, зпатме, &1оса1, "цар" ); 

6 $ = зоскее( АЕ_ТМЕТ, $О0СК_ОСВАМ, 0}; 

7 1Е ( !15уа11азосКк( ® } ) 

8 еггог( 1, е’ггпо, "ошибка вызова зоскее" }; 
9 1Е ( БЬ1ра( 3, ( зЕгасЕ зоскааахг * ) &1оса1, 
10 $12е0Ё( 1оса1 } ) )} 
11 егхог( 1, егхпо, "ошибка вызова Б1па" }; 
12 гебиги з; 

13} 

иар_5егуег.с 

Каркас ИБР-клиента 


Функция ма1п в каркасе ООР-клиента выполняет в основном запись в поля 
переменной реехг указанных адреса и номера порта сервера и получает сокет типа 
$0СК_ОСВАМ. Она показана в листинге 2.10. Весь остальной код каркаса такой же, 
как для чарзегуег. зКе]. 


Листинг 2.10. Функция тат из каркаса чарсйет.зКе! 


очами Юон 


иарс]1епЕ. ке] 


106 ша1п( 106 агас, сВаг **агау ) 
{ 
$ЕгисЕ зоскаааг_1п реег; 
бОСКЕТ 3; 
ТМТТ(); 
зе’_аЯЯгез$( агду[ 1 ], агду[ 2 ], &реег, "аар" ); 
5 = зоскеб( АР _ТМЕТ, $О0ОСК_ОСВАМ, 0}; 
1Е ( !1зуа11азоск( ®з ) ) 


еггог( 1, еггпо, "ошибка вызова зоскКес“ )}; 


с11епЁ ( $, &реег ); 
ех1е (0) 


: 


иарс11епЁ.5Ке]1 


Теперь можно протестировать одновременно этот каркас и программу иарне11о, 
для чего необходимо скопировать идрс11епе .зке1 в файл царНе11ос.с и вместо 
клиентской заглушки подставить такой код: 
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скае1с \01@Я с11епё( $ЗОСКЕТ з, зекисе зоскаЯах_1п *реегр } 
{ 


106 гс; 
1пЕ реег1еп; 
спахг БаЕ[ 120 ]; 


реег1еп = $512ео0оЕ( *реегр }; 
1Е ( зепаво( з, "", 1, 0, ( вегиасЕ зосКаааг * }реегр, 
реег]еп } < 0 } 
еггохг( 1, еггпо, "ошибка вызова зепабо" )}; 
ус = гесуЕгот( $, РаЁ, э1хеоЁ( БаЕ }, 0, 
( зегисЕ зоскаааг * )реегр, &реег1еп )}; 
1Е (ус >= 0} 
ми16е(1, БЕ, тс }; 
е15е 
еггог( 1, еххгпо, "ошибка вызова гесуУЁгом" )}; 


} 


Функция с11епе посылает серверу нулевой байт, читает возвращенную дата- 
грамму, выводит ее в стандартное устройство вывода и завершает программу. Функ- 
ции гесуЁгом в коде иарпе11о вполне достаточно одного нулевого байта. После 
его приема она возвращает управление основной программе, которая и посылает 
ответную датаграмму. 

При одновременном запуске обеих программ выводится обычное приветствие: 


Ьза: $ чарье11о 9000 & 

[1} 448 

Ьза: $ чраве11ос 1оса1Вов® 9000 
Ве11о, мог1а 

Ьза: $ 


Как всегда, следует вынести стартовый код из ма1п вбиблиотеку, Обратите вни- 
мание, что библиотечной функции, которой дано имя чар_с11епе (листинг 2.11), 
передается третий аргумент - адрес структуры зоскааах_1п; в нее будет помещен 
адрес и номер порта, переданные в двух первых аргументах. 


#1пс1а@ае "ебср.В" 


| ЗОСКЕТ цар_с11епЕ( сраг *РозЕЁ, сваг *рогЕ, | 

зЕхгисе зоскаааг 1п *зар )}; | 
| Возвращаемое значение: ЧОР-сокет и заполненная структура РОКА 
(в случае ошибки завершает программу). 


Листинг 2. 11. Функция иар_сйет 


иЯр_с11епрЕЁ.с 


1 5ОСКЕТ чар_с11ере( спахг *Рпаше, сКах *зпаше, 
2 зЕкисе зоскааЯк 1п *вар )} 

3 { 

4 ЗОСКЕТ $5; 
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5 зе ааЯгезз( Ппаме, эзпаме, зар, "а@ар" ); 

6 $ = сосКеё( АЕ _ТМЕТ, $ОСК_ОСВАМ, 0); 

7 1Е ( 1!1вУуа11Азоск( ® ) } 

8 еггохг( 1, еггпо, “ошибка вызова зоскее" ); 

9 тебцип 3; 

10 } 

иар_с]лепЕ.с 

Резюме 


Прочитав данный раздел, вы узнали, как просто создать целый арсенал карка- 
сов и библиотечных функций. Все построенные каркасы очень похожи и различа- 
ются только несколькими строками в стартовом коде внутри функции ма1п. Та- 
ким образом, после написания первого каркаса пришлось лишь скопировать код 
и подправить эти несколько строк. Эта методика очень проста. Поэтому, чтобы со- 
здать несколько элементарных клиентов и серверов, потребовалось только вста- 
вить содержательный код вместо заглушек. 

Использование каркасов и написание библиотечных функций закладывает тот 
фундамент, на котором далее легко строить приложения и небольшие тестовые 
программки для их проверки. 


Совет 5. Предпочитайте интерфейс сокетов 
интерфейсу ХТИТЫ 


В мире ОХ в качестве интерфейса к коммуникационным протоколам, в част- 
ности к ТСР/ТР, в основном используются следующие два АР]: 


о сокеты Беркли; 
о транспортный интерфейс ХТКХ/Ореп Тгапзрогё ПиегЁасе). 


Интерфейс сокетов разработан в Университете г. Беркли штата Калифорния 
и вошел в состав созданной там же версии операционной системы ОМХ. Он полу- 
чил широкое распространение вместе с версией 4.2В$Ш (1983), затем был усовер- 
шенствован в версии 4.3ВЗО Вепо (1990) и теперь включается практически во все 
версии ОМХ. АРГ сокетов присутствует и в других операционных системах. Так, 
УЙпзоск АРТ популярной в мире Мусгозой УЯп4о\з основан на сокетах из ВЗР 
[УИлзосК Стоцр 1997]. 

АР! интерфейса ХТ] - это расширение интерфейса к транспортному уровню 
(Тгапзрогё Гауег Пцегасе — ТТЛ), который впервые появился в системе ОМХ Зузет 
У Вавазе 3.0 (5УВЗ) компании АТ&Т. ТЫ задумывался как интерфейс, не завися- 
щий от протокола, так как он сравнительно легко поддерживает новые протоколы. 
На его дизайн оказала значительное влияние модель протоколов ОЗТ (совет 14). 
В то время многие полагали, что эти протоколы вскоре придут на смену ТСР/ТР. 
И поэтому, с точки зрения программиста ТСР/1Р, дизайн этого интерфейса далек 
отоптимального. Кроме того, хотя имена функций ТЦ очень похожи на использу- 
емые в АРТ сокетов (только они начинаются с *_), их семантика в ряде случаев 
кардинально отличается. 
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Тот факт, что интерфейс ТГ все еще популярен, возможно, объясняется его 
использованием с протоколами [т\егпе\могк РасКкеё Ехсрапзе/Зедиепсей Раске 
ЕхсБапёе (1РХ/5РХ) в системах фирмы Моуе|. Поэтому при переносе программ, 
написанных для [РХ/ЗРХ, под ТСР/1Р проще было воспользоваться тем же ин- 
терфейсом ТТЛ [КасКег 1999]. 

В четвертой части первого тома книги «ОМТХ МебхогК Ргоргатиитя» [5%еуепз 
1998] имеется прекрасное введение в программирование ХТ]! и подсистемы 
ЗТКЕАМ$. Представить, насколько отличается семантика ХТ] и сокетов, можно 
хотя бы по тому, что обсуждению ХТ] посвящено более 100 страниц. 

Надеясь, что протоколы ОЗ] все-таки заменят ТСР/ТР, многие производители 
ОМТГХ-систем рекомендовали писать новые приложения с использованием ТП 
АРТ. Одна фирма-производитель даже заявила, что интерфейс сокетов не будет 
поддерживаться в следующих версиях. Но такие прогнозы оказались несколько 
преждевременными. 

Протоколы ОЗ] можно считать устаревшими, но ТЦ и последовавший за ним 
ХТ! все еще поставляются в составе ОМХ-систем, производных от Зузет У. По- 
этому при программировании для МХ встает вопрос: что лучше использовать -- 
сокеты или ХТ[? 

Здесь необходимо напомнить, почему указанные протоколы называются ин- 
терфейсами. Для программиста ТСР/ТР это всего лишь разные способы доступа 
к стеку ТСР/ТР. Поскольку именно этот стек реализует коммуникационные про- 
токолы, не имеет значения, какой АР] использует его клиент. Это означает, что 
приложение, написанное с помощью сокетов, может обмениваться данными с при- 
ложением на базе ХТ1. В системах типа 5УК4 оба интерфейса обычно реализуют- 
ся в виде библиотек, осуществляющих доступ к стеку ТСР/Р с помощью подсис- 
темы З5ТКЕАМ5. 

Рассмотрим сначала интерфейс ХЛТ. У него есть своя ниша в сетевом програм- 
мировании. Поскольку он не зависит от протокола, с его помощью можно добавить 
в систему ОМШХ новый протокол, не имея доступа к коду ядра. Проектировщику про- 
токола необходимо лишь реализовать транспортный провайдер в виде ЗТКЕАМ5- 
мультиплексора, связать его с ядром, а потом обращаться к нему через ХТ|. 


Примечание О том, как писать модули $5ТКЕАМ5, а также о программиро- 
вании ТЫ и 5ТКЕАМ$ вы можете прочесть в книге [Каро 1993], 


Обратите внимание, насколько специфична ситуация: нужно реализовать от- 
сутствующий в системе протокол, когда нет доступа к исходным текстам ядра. 


Примечание Кроме того, этот протокол нужно разработать для системы 
5УЁ4 или любой другой, поддерживающей УТКЕАМ5 и ХТИТИ. 
Начиная с версии б9апз 2.6, фирма 5ип предоставляет такую 
же функциональность с помощью АРГ сокетов. 


Иногда утверждают, что проще писать не зависящий от протокола код с по- 
мощью ХТИ/ТИГЛ [Ваво 1993]. Конечно, «простота» — понятие субъективное, но 
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в разделе 11.9 книги «УМХ Меёмогк Рговгатиип8» Стивенс с помощью сокетов 
реализовал простой, не зависящий от протокола сервер времени дня, который под- 
держивает [Р версии 4, [Р версии 6 и сокеты в адресном домене ОМХ. 

И, наконец, говорят, что при поддержке обоих интерфейсов сокеты обычно 
реализуются поверх ТГЛ/ХТТ, так что ТЫ/ХТТ более эффективен. Это не так. Как 
отмечалось выше, в системах на базе ЗУ ВА оба интерфейса обычно реализованы 
в виде библиотек, напрямую общающихся с подсистемой ЗТКЕАМ. Фактически 
с версии Зо[а11$ 2.6 (Зо|аг1 — это версии ЗУ КА, созданные фирмой Зип) сокеты ре- 
ализованы непосредственно в ядре; обращение к ним происходит через вызовы 
системы. 

Большое преимущество сокетов — переносимость. Поскольку сокеты есть прак- 
тически во всех системах с ХТИТИ, их использование гарантирует максималь- 
ную переносимость. Даже если ваше приложение будет работать только под МХ, 
так как большинство операционных систем, поддерживающих ТСР/1Р предостав- 
ляет интерфейс сокетов. И лишь немногие системы, не принадлежащие к ОМХ, 
содержат интерфейс ХТТ/ИТЫ (если вообще такие существуют). Например, созда- 
ние приложения, переносимого между ОМХ и М!сгозой УЛп4о\, — сравнительно 
несложная задача, так как \Ло4о\$ поддерживает спецификацию УЙпзоск, в кото- 
рой реализован АР] сокетов. 

Еще одно преимущество сокетов в том, что этот интерфейс проще использо- 
вать, чем ХТИТЦ. Поскольку ХТИТЫ проектировался в основном как общий 
интерфейс (имеются в виду протоколы ОЗ$Т), программисту приходится при его 
использовании писать больше кода, чем при работе с сокетами. Даже сторонники 
ХТИТЫ согласны с тем, что для создания приложений ТСР/Р следует предпо- 
честь интерфейс сокетов. 

Руководство «Введение в библиотеку подпрограмм», поставляемое в составе 
Зо[ат1з 2.6, дает такой совет по выбору АР!: «При всех обстоятельствах рекоменду- 
ется использовать АРТ сокетов, а не ХТТи ТЫ. Если требуется переносимость на 
другие системы, удовлетворяющие спецификации ХРСУ4\2, то следует исполь- 
зовать интерфейсы из библиотеки ПЬхпей. Если же переносимость необязательна, 
то рекомендуется интерфейс сокетов из библиотек 1Ьзоске{ и 1Ьп3|, а не из НЬхпей. 
Если выбирать между ХТ! и ТИ, то лучше пользоваться интерфейсом ХТТ (до- 
ступным через ШБхпей), а не ТЫ (доступным через 16 п3])». 


Резюме 


В обычных ситуациях нет смысла использовать интерфейс ХТИТЫ при про- 
граммировании ТСР/ТР. Интерфейс сокетов проще и обладает большей переноси- 
мостью, а возможности обоих интерфейсов почти одинаковы. 


Совет 6. Помните, что ТСР - потоковый протокол 


ТСР - потоковый протокол. Это означает, что данные доставляются получа- 
телю в виде потока байтов, в котором нет понятий «сообщения» или «границы 
сообщения». В этом отношении чтение данных по протоколу ТСР похоже на чте- 
ние из последовательного порта - заранее не известно, сколько байтов будет воз- 
вращено после обращения к функции чтения. 
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Представим, например, что имеется ТСР-соединение между приложениями 
на хостах А и В. Приложение на хосте А посылает сообщения хосту В. Допустим, 
что у хоста А есть два сообщения, для отправки которых он дважды вызывает 
зепа - по разу для каждого сообщения. Естественно, эти сообщения передаются 
от хоста А к хосту В в виде раздельных блоков, каждое в своем пакете, как пока- 
зано на рис. 2.13. 

К сожалению, реальная передача данных вероятнее всего будет происходить 
нетак. Приложение на хосте А вызывает зепа, и вроде бы данные сразу же переда- 
ются на хост В. На самом деле зепа обычно просто копирует данные в буфер стека 
ТСРИТР на хосте А и тут же возвращает управление. ТСР самостоятельно опреде- 
ляет, сколько данных нужно передать немедленно. В частности, он может вообще 
отложить передачу до более благоприятного момента. Принятие такого решения 
зависит от многих факторов, например: окна передачи (объем данных, которые 
хост В готов принять), окна перегрузки (оценка загруженности сети), максималь- 
ного размера передаваемого блока вдоль пути (максимально допустимый объем 
данных для передачи в одном блоке на пути от А кВ) и количества данных в выход 
ной очереди соединения. Подробнее это рассматривается в совете 15. На рис. 2.14 
показано только четыре возможных способа разбиения двух сообщений по паке- 
там. Здесь М ни М ‚›- первая и вторая части сообщения М „а МниМ,, - соответ- 
ственно части М,. Как видно из рисунка, ТСР не всегда посылает все сообщения 
в одном пакете. 


а) [1 М№| [М 
6) [№ || 
в) [М2] М м | 
м 
| жел МГ МГ] жетв. г) | ММ» М | 


Рис. 2.14. Четыре возможных 
Рис. 2.13. Неправильная модель способа разбиения 
отправки двух сообщений двух сообщений по пакетам 


А теперь посмотрим на эту ситуацию с точки зрения приложения на хосте. 
В общем случае оно не имеет информации относительно количества возвращае- 
мых ТСР данных при обращении к системному вызову гесу. Например, когда при 
ложение на хосте В в первый раз читает данные, возможны следующие варианты 


О данных еще нет, и приложение либо блокируется операционной системой 
либо гесу возвращает индикатор отсутствия данных. Это зависит от того, 
был ли сокет помечен как блокирующий и какую семантику вызова гесу 
поддерживает операционная система; 

О приложение получает лишь часть данных из сообщения М,, если ТСР по- 
сланы пакеты так, как показано на рис. 2.14г; 

о приложение получает все сообщение М, если ТСР отправлены пакеты, как 
изображено на рис. 2.14а; 
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о приложение получает все сообщение М; и часть или все сообщение М, как 
представлено на рис. 2.14в. 


НИ Е ЕЕ ИЕН 

Примечание В действительности таких вариантов больше, так как здесь не 
учитывается возможность ошибки и получения конца файла. 
Кроме того, предполагается, что приложение читает все до- 
ступные данные. 


Значительную роль здесь играет время. Если приложением на хосте В пер- 
вое сообщение прочитано не сразу после его отправки, а спустя некоторое время 
после того, как хост А послал второе, то будут прочитаны оба сообщения. Как 
видите, количество данных, доступных приложению в данный момент, - вели- 
чина неопределенная. 

Еще раз следует подчеркнуть, что ТСР -— потоковый протокол и, хотя данные 
передаются в [Р-пакетах, размер пакета напрямую не связан с количеством дан- 
ных, переданных ТСР при вызове зепа. У принимающего приложения нет надеж- 
ного способа определить, как именно данные распределены по пакетам, поскольку 
между соседними вызовами хесу может прийти несколько пакетов. 


Примечание Это может произойти, даже если принимающее приложение ре- 
агирует очень быстро. Например, если один пакет потерян (впол- 
не обычная ситуация в [щетеь, см. совет 12), а последующие 
пришли нормально, то ТСР «придерживает» поступившие дан- 
ные, пока не будет повторно передан и корректно принят про- 
павший пакет. В этот момент приложение получает данные из 
всех поступивших пакетов. 


ТСР следит за количеством посланных и подтвержденных байтов, но не за их 
распределением по пакетам. В действительности, одни реализации при повторной 
передаче потерянного пакета посылают больше данных, другие - меньше. Все это 
настолько важно, что заслуживает выделения: Для ТСР-приложения нет понятия 
«пакет». Если приложение хоть как-то зависит от того, как ТСР распределяет 
данные по пакетам, то его нужно перепроектировать. 

Так как количество возвращаемых в результате чтения данных непредсказуе- 
мо, вы должны быть готовы к обработке этой ситуации. Часто проблемы вообще 
не возникает. Допустим, вы пользуетесь для чтения данных стандартной библио- 
течной функцией Едеез. При этом она сама будет разбивать поток байтов на стро- 
ки (листинг 3.3). Иногда границы сообщений бывают важны, тогда приходится ре- 
ализовывать их сохранение на прикладном уровне. 

Самый простой случай -— это сообщения фиксированной длины. Тогда вам нуж- 
но прочесть заранее известное число байтов из потока. В соответствии с вышеска- 
занным, для этого недостаточно выполнить простое однократное чтение: 


хесу( $5, пза, $з12е0оЕ( пза ), 0); 


поскольку при этом можно получить меньше, чем з12еоЁ( тзд ) байт (рис. 2.14г). 
Стандартный способ решения этой проблемы показан в листинге 2.12. 
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Листинг 2. 12. Функция геадп 


геаап.с 

1 116 геаап( ЗОСКЕТ ЕЯ, свах *Ър, з12е_6 1еп) 

2 

3 11 спе; 

4 тп тс; 

5 спё = 1еп; 

6 мр11е ( спЕёЁ > 0 ) 

7 { 

8 гс = гесу( Еа, ор, спе, 0); 

9 Е сте < 0) /* Ошибка чтения? */ 

10 { 

11 3ЁЕ ( егхпо == ЕШУМТА ) /* Вызов прерван? */ 

12 сопЕ1тце; /* Повторить чтение. */ 

13 тебихуй -1; /* Вернуть код ошибки. */ 

14 } 

15 1Е ( кс == ) /* Конец файла? */ 

16 тебауп 1еп - спе; /* Вернуть неполный счетчик. */ 
17 Ьр += гс; 

18 спе -= гс; 

19 } 
20 гебаги 1еп; 
21} 

геаап. с 


Функция геадп используется точно так же, как геаа, только она не возвраща- 
ет управления, пока не будет прочитано 1еп байт или не получен конец файла или 
не возникнет ошибка. Ее прототип выглядит следующим образом: 


= — = =—— = — ыы ——_——_—о— 


#1пс1аае «ебср.Н» 
106 геадп( ЗОСКЕТ $, спаг *БиЁ, в1тхе_е 1еп }; 


Возвращаемое значение: число прочитанных байтов или -1 в случае ошибки. 


| ОАО РЕВ БЕ ОЗНА ВОН ВИ ВЕН ОИ ЗЕНА ЕВ БЕН Е ЕЕ НОЕ ЕНИСЕЯ 

Неудивительно, что геади использует ту же технику для чтения заданного 
числа байтов из последовального порта или иного потокового устройства, когда 
количество данных, доступных в данный момент времени, неизвестно. Обычно 
геадл (с заменой типа ЗОСКЕТ на 1п6 и гесу на геаа) применяется во всех этих 
ситуациях. 

Оператор Е 

1Е ( еггпо == ЕТМВ ) 
сопё1пае; 


в строках 11 и 12 возобновляет выполнение вызова гесу, если он прерван сигна- 
лом. Некоторые системы возобновляют прерванные системные вызовы автомати- 
чески, в таком случае эти две строки не нужны. С другой стороны, они не мешают, 
так что для обеспечения максимальной переносимости лучше их оставить. 
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Если приложение должно работать с сообщениями переменной длины, то 
в вашем распоряжении есть два метода. Во-первых, можно разделять записи спе- 
циальными маркерами. Именно так надо поступить, используя стандартную функ- 
цию Едеез для разбиения потока на строки. В этом случае естественным разде- 
лителем служит символ новой строки. Если маркер конца записи встретится в теле 
сообщения, то приложение-отправитель должно предварительно найти в сообще- 
нии все такие маркеры и экранировать их либо закодировать как-то еще, чтобы 
принимающее приложение не приняло их по ошибке за конец записи. Например, 
если в качестве признака конца записи используется символ-разделитель ВК$, то 
отправитель сначала должен найти все вхождения этого символа в тело сообще- 
ния и экранировать их, например, добавив перед каждым символ \. Это означает, 
что данные необходимо сдвинуть вправо, чтобы освободить место для символа эк- 
ранирования. Его, разумеется, тоже необходимо экранировать. Так, если для экра- 
нирования используется символ \, то любое его вхождение в тело сообщения сле- 
дует заменить на \\. 


Другие данные в заголовке 


Заголовок 


Данные переменной длины 


Рис. 2.15 
Формат записи переменной длины 


Принимающей стороне нужно просмотреть все сообщение, удалить символы 
экранирования и найти разделители записей. Поскольку при использовании мар- 
керов конца записи все сообщение приходится просматривать дважды, этот метод 
лучше применять только при наличии «естественного» разделителя, например 
символа новой строки, разделяющего строки текста. 

Другой метод работы с сообщениями переменной длины предусматривает 
снабжение каждого сообщения заголовком, содержащим (как минимум) длину 
следующего за ним тела. Этот метод показан на рис. 2.15. 

Принимающее приложение читает сообщение в два приема: сначала заголовок 
фиксированной длины, и из него извлекается переменная длина тела сообщения, 
а затем - само тело. В листинге 2.13 приведен пример для простого случая, когда 
В заголовке хранится только длина записи. 


Листинг 2.13. Функция для чтения записи переменной длины 


геааугес. с 


116 геа@угес( ЗОСКЕТ ЁЕа, снах *Ър, з12е_6 1еп ) 


1 
2 { 

3 ц_10632_Е гес1еп; 
4 116 гс; 

5 


/* Прочитать длину записи. */ 


СЗО ПИ В ВИ 


Основы 


<17еоЁ( ч_1п632_6 ) }; 


геаЯугес.с 


6 ус = геаар( Га, ( спахг * }&хес1ел, 
й, 1Ё ( кс != з12еоЁ( ц_10632_6 ) } 
8 тебагл гс < 0? -1 0 
9 гес1еп = пбор1( гес]еп ); 
10 1Е ( гес]еп > 1еп ) 
11 { 
12 ты 
13 * Не хватает места в буфере для размещения данных - 
14 отбросить их и вернуть код ошибки. 
15 * / 
16 у11е ( гес1епт > 0) 
17 { 
18 гс = геаап( Еа, Бр, 1еп }; 
19 1Е ( гс != 1еп } 
20 гебсаги гс < 0? -1 0; 
21 гес1еп -= 1еп; 
22 1Е ( гес1еп < 1ел ) 
23 ]1еп = гес1еп; 
24 } 
25 зеё_ехгупо( ЕМУСЯУТЕЕ }; 
26 гевигп -1; 
27 } 
28 /* Прочитать саму запись */ 
29 гс = геаап( ЕЯ, Бр, гес1епт ); 
30 1Е (гс != гес1ел ) 
31 гебагл гс < 0? -1 0; 
32 гесахгп гс; 
33 } 
Чтение длины записи 
6-8 


Длина записи считывается в переменную гес1еп. Функция геадугес 


возвращает 0 (конец файла), если число байтов, прочитанных геадп, 
не точно совпадает с размером целого, или —1 в случае ошибки. 

9 Размер записи преобразуется из сетевого порядка в машинный. Под- 
робнее об этом рассказывается в совете 28. 


Проверка того, поместится ли запись в буфер 

10-27 Проверяется, достаточна ли длина буфера, предоставленного вызываю- 
щей программой, для размещения в нем всей записи. Если места не хва- 
тит, то данные считываются в буфер частями по 1еп байт, то есть, по 
сути, отбрасываются. Изъяв из потока отбрасываемые данные, функция 
присваивает переменной еггпо значение ЕМ$СЗТРЕ и возвращает -1. 


Считывание записи 


29-32 Наконец считывается сама запись. геадугес возвращает -1, 0 или 
гес]1еп в зависимости от того, вернула ли геаап код ошибки, непол- 
ный счетчик или нормальное значение. 


ТСР - потоковый протокол 


НК 


ЕЕ И И ИХ 


Поскольку хеадугес — функция полезная и ей найдется применение, необхо- 
димо записать ее прототип: 
#1пс1аае "ебср.Ь" 
116 геааугес( ЗОСКЕТ $, сраг *БиЕЁ, з12е_6 1еп )}; 


Возвращаемое значение: число прочитанных 6 байтов или -1. 


В листинге 2.14 дан пример простого сервера, который читает из ТСР-соеди- 
нения записи переменной длины с помощью геадугес и записывает их на стан- 
дартный вывод. 


Листинг 2. 14. уг$ - сервер, демонстрирующие применение функции геадугес 


уг5. Сс 

1 #1ис1аае "ебср.В" 

2 1пЕ ма1п( 116 ахгас, стаг **акдау ) 

м 

4 зЕкисЕ зоскКааау_1п реек; 

5 ЗОСКЕТ з; 

6 СОСКЕТ $1; 

7 106 реех’1еп = з12еоЁ( реег ); 

8 ИЕ п 

9 сваг БаЕЁ[ 10 }]; 

10 УМ (9; 

11 1Е ( акас == 2 ) 

12 з = Еср_зегуех( МТ, агау[ 1 ] ); 

13 е1зе 

14 5 = Сср_зекуег( агаду[ 1 ], акау[ 2 ] ); 

15 $51 = ассере( 5$, ( з6кисЕ зосКаааг * }&реег, &реег1епт ); 
16 1Е ( 1!1°зуа11азосКк( $1 ) ) 

17 еггог( 1, ехгпо, "ошибка вызова ассерё" }; 

18 Бог (;; ) 

19 { 
20 п = геадукес( $1, БаЕЁ, з12еоЁ( БаЕ ) }; 

21 Е (п <0) 

22 егхгог( 0, еггпо, "геааугес вернула код ошибки" ); 
23 е1зе 1ЕЁ ( == ) 
24 егхох ( 1, 0, "клиент отключился\п" ); 

25 е1зе 

26 иг1е( 1, ЮРМЕ, п}; 
27 } 
28 ЕХТТ( О); /* Сюда не попадаем. */ 

29 } 

УГ5.С 


10-17 Инициализируем сервер и принимаем только одно соединение. 
20-24 Вызываем геадугес для чтения очередной записи переменной длины. 
Если произошла ошибка, то печатается диагностическое сообщение 
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и читается следующая запись. Если геадугес возвращает ЕОЁ то пе- 
чатается сообщение и работа завершается. 
26 Выводим записи на зЕдоце. 


В листинге 2.15 приведен соответствующий клиент, который читает сообще- 
ния из стандартного ввода, добавляет заголовок с длиной сообщения и посылает 
все это серверу. 


Листинг 2. 15. угс - клиент, посылающий записи переменной длины 


Уга:е 
1 #1ипс1аае "ебёср.В" 

2 116 па1п( 116 агас, свВаг **агду } 

3 { 

4 ЗОСКЕТ 38; 

5 1п6 п; 

6 зЕгасЕ 

7 { 

8 1_10632_6 гес1еп; 

9 спаг БаЕ[ 128 ]; 

10 } расКеЕ; 

11 ТМТТ(); 
12 з = Еср_с11епе( агау[ 1 |], агау[ 2] ); 
13 \111е ( ЕдеЕёз( расКее.БиЁ, з12еоЁ( раскее.рБиЕ ), зеа1т )} 
14 1= мМШ ) 
15 { 

16 п = з6:1еп( раскее.БаЕ ); 

17 расКеё.гес1еп = Пёоп] (п }; 

18 1Е ( зепЯа( зв, ( спаг * )&раскее, 

19 п + 812ео0оЁ( раскеё.гес1еп ), 0) <0) 
20 еггог( 1, еггпо, "ошибка вызова зепа" }; 
21 } 
22 ЕХТТ( о); 
23 } 

угс. с 


Определение структуры раске! 

6-10 Определяем структуру раскКек, в которую будем помещать сообщение 
и его длину перед вызовом зепа. Тип данных ц_1132_6 - это беззна- 
ковое 32-разрядное целое. Поскольку в \Лпо\з такого типа нет, в вер- 
сии заголовочного файла эке1 .п для \УЛп4о\з приведено соответству- 
ющее определение типа. 


Примечание В этом примере есть одна потенциальная проблема, о которой 
следует знать. Предположим, что компилятор упаковывает 
данные в структуру, не добавляя никаких символов заполнения. 
Поскольку второй элемент -— это массив байтов, в большин- 
стве систем это предположение выполняется, но всегда нужно 
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помнить о возможной недостоверности допущений о способе 
упаковки данных в структуру компилятором. Об этом будет 
рассказано в совете 24 при обсуждении способов для отправки 
нескольких элементов информации одновременно. 


СоппесЕ, геа4 и 5еп4 

6-10 — Клиент соединяется с сервером, вызывая функцию Е ср_с11епе. 

13-21 Вызывается Едеёз для чтения строки из стандартного ввода. Эта стро- 
ка помещается в пакет сообщения. С помощью функции зЕг1еп опре- 
деляется длина строки. Полученное значение преобразуется в сетевой 
порядок байтов и помещается в поле гес1еп пакета. В конце вызыва- 
ется зепа для отправки пакета серверу. 


Другой способ отправки сообщений, состоящих из нескольких частей, рассмат- 
ривается в совете 24. 

Протестируем эти программы, запустив сервер на машине зрагс, а клиент — 
на машине Ъза. Поскольку результаты показаны рядом, видно, что поступает на 
вход клиенту и что печатает сервер. Чтобы сообщение строки 4 уместилось на стра- 
нице, оно разбито на две строчки. 


за: $ угс врагс 8050 зрагс: $ угв 8050 


123 123 

123456789 123456789 

1234567890 угз: геааугес вернула код ошибки: 
Меззаде соо 1опа (97) 

12 12 

^С угз: клиент отключился 


Поскольку длина буфера сервера равна 10 байт, функция геадугес возвраща- 
ет код ошибки, когда отправляется 11 байт 1,..., 0,<Г.Е>. 


Резюме 


Типичная ошибка, допускаемая начинающими сетевыми программистами, — 
в непонимании того, что ТСР доставляет поток байтов, в котором нет понятия 
«границы записей». В ТСР нет видимой пользователю концепции «пакета». Он 
просто передает поток байтов, и нельзя точно предсказать, сколько байтов будет 
возвращено при очередном чтении. В этом разделе рассмотрено несколько спо- 
собов работы в таких условиях. 


Совет 7. Не надо недооценивать 
производительность ТСР 


ТСР - это сложный протокол, обеспечивающий базовую службу доставки ГР- 
датаграмм надежностью и управлением потоком. В то же время ОПР добавляет 
лишь контрольную сумму. Поэтому может показаться, что ОЮР должен быть на 
порядок быстрее ТСР. Исходя из этого предположения, многие программисты по- 
лагают, что с помощью ОБР можно достичь максимальной производительности. 


СР Основы 


Да, действительно, есть ситуации, когда (ОР существенно быстрее ТСР. Но ино- 
гда использование ТСР оказывается эффективнее, чем применение ОПР. 

В сетевом программировании производительность любого протокола зависит 
от сети, приложения, нагрузки и других факторов, из которых не последнюю роль 
играет качество реализации. Единственный надежный способ узнать, какой прото- 
кол и алгоритм работают оптимально, — это протестировать их в предполагаемых 
условиях работы приложения. На практике это, конечно, не всегда осуществимо, но 
часто удается получить представление о производительности, воспользовавшись 
каркасами для построения простых программ, моделирующих ожидаемый сетевой 
трафик. 

Перед созданием тестовых примеров необходимо разобраться, когда и почему 
производительность ОЮР больше, чем ТСР. Прежде всего, поскольку ТСР слож- 
нее, он выполняет больше вычислений, чем (ОР 


Примечание В работе [54е0еп5, 1996 ] сообщается, что реализация ТСР в си- 
стеме 4.4 В5О содержит примерно 4200 строк кода на языке С 
в сравнении с 800 строками для ПОР. Естественно, обычно вы- 
полняется намного меньше строк, но эти числа отражают срав- 
нительную сложность кода. 


Но в типичной ситуации большая часть времени процессора в обоих прото- 
колах тратится на копирование данных и вычисление контрольных сумм (совет 26), 
поэтому здесь нет большой разницы. В своей работе [Раги14ее 1993] Джекоб- 
сон описывает экспериментальную версию ТСР в которой для выполнения всего 
кода обычно требуется всего 30 машинных инструкций К]$5С (исключая вычисле- 
ние контрольных сумм и копирование данных в буфер пользовательской програм- 
мы, которые производятся одновременно). 

Нужно отметить, что для обеспечения надежности ТСР должен посылать под- 
тверждения (АСК-сегменты) на каждый принятый пакет. Это несколько увеличи- 
вает объем обработки на обоих концах. Во-первых, принимающая сторона может 
включить АСК в состав данных, которые она посылает отправителю. В действи- 
тельности во многих реализациях ТСР отправка АСК задерживается на несколь- 
ко миллисекунд: предполагается, что приложение-получатель вскоре сгенерирует 
ответ на пришедший сегмент. Во-вторых, ТСР не обязан подтверждать каждый 
сегмент. В большинстве реализаций при нормальных условиях АСК посылается 
только на каждый второй сегмент. 


Примечание ВЕС 1122 [Втааеп 1989] рекомендует откладывать посылку АСК 
до 0,5 с при подтверждении каждого второго сегмента. 


Еще одно принципиальное отличие между ТСР и ОПР втом, что ТСР требует 
логического соединения (совет 1) и, значит, необходимо заботиться об его уста- 
новлении и разрыве. Для установления соединения обычно требуется обменяться 
тремя сегментами. Для разрыва соединения нужно четыре сегмента, которые, кро- 
ме последнего, часто можно скомбинировать с сегментами, содержащими данные. 


Производительность ТСР 
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Предположим, что время, необходимое для разрыва соединения в большин- 
стве случаев не расходуется зря, поскольку одновременно передаются данные. 
Следует выяснить, что же происходит во время установления соединения. Как 
показано на рис. 2.16, клиент начинает процедуру установления соединения, по- 
сылая серверу сегмент ЗУМ (синхронизация). В этом сегменте указывается поряд- 
ковый номер, который клиент присвоит первому посланному байту, а также дру- 
гие параметры соединения. В частности, максимальный размер сегмента (М55), 
который клиент готов принять, и начальный размер окна приема. Сервер в ответ 
посылает свой сегмент ЗУМ, который также содержит подтверждение АСК на сег- 
мент ЗУМ клиента. И, наконец, клиент отсылает АСК на сегмент ЗУМ сервера. На 
этом процедура установления соединения завершается. Теперь клиент может по- 
слать свой первый сегмент данных. 

На рис. 2.16 ВТТ (гоцп4-и1р Ите) — это 
период кругового обращения, то есть время, Клиент Сервер 
необходимое пакету для прохождения с одно- 
го хоста на другой и обратно. Для установле- 
ния соединения нужно полтора таких периода. 

При длительном соединении между кли- 
ентом и сервером (например, клиент и сервер 
обмениваются большим объемом данных) ука- 
занный период «размазывается» между всеми 
передачами данных, так что существенного 
влияния на производительность это не оказы- 
вает. Однако если речь идет о простой транзак- 
ции, в течение которой клиент посылает за- 
прос, получает ответ и разрывает соединение, Рис. 2.16. Установление 
то время инициализации составляет заметную соединения 
часть от времени всей транзакции. Таким об- 
разом, следует ожидать, что (ОР намного превосходит ТСР по производительно- 
сти именно тогда, когда приложение организует короткие сеансы связи. И, наоборот, 
ТСР работает быстрее, когда соединение поддерживается в течении длительного 
времени при передаче больших объемов данных. 

Чтобы протестировать сравнительную производительность ТСР и ОБР, аза- 
одно продемонстрировать, как пишутся небольшие тестовые программки, созда- 
дим несколько простых серверов и клиентов. Здесь имеется в виду не полнофунк- 
циональная контрольная задача, а лишь определение производительности двух 
протоколов при передаче большого объема данных. Примером такого рода прило- 
жения служит протокол ЕТР. 


И/>ВТТ 


Источник и приемник на базе ЦОР 


В случае ОБР клиент посылает нефиксированное количество датаграмм, ко- 
торые сервер читает, подсчитывает и отбрасывает. Исходный текст клиента при- 
веден в листинге 2.16. 
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Листинг 2. 16. ЦОР-клиент, посылающий произвольное число датаграмм 


иарзоигсе. с 
1 #1пс1аае "еёср.В" 

2 1пЕ па1п( 1106 агдс, сраг **агду } 

3: = 

4 зЕгисЕ зоскКадаг_1п реег; 
5 ЗОСКЕТ в; 

6 1106 гс; 

7 116 аабадгатз; 

8 1106 Аадгамвес = 1440; 

9 сраг БаЁ[ 1440 |; 


10 ТМТТ(); 

13 Засачгамз = або1( агау[ 2 ] ); 
12 1Е ( агас > 3) 

13 аагатз7 = або1( агау[ 3 ] ); 


14 3 = Чар_с13епб( агду[ 1 ], "9000", &реег ); 
15 \й:1е ( Забаагамз-- > 0 ) 


16 { 

17 гс = зергабо( з, БаЕЁ, адгатес, 0, 

18 ( ЗЕГиСЕ воскКа@аг * )&реехг, з212еоЁ( реег ) ); 
19 Ета) 

20 еггог( 0, еггпо, "ошибка вызова зепабо" }; 

21 } 

22 зепабо( з, "", 0, 0, 

23 ( зЕгисЕ зоска@аг * })&реег, з12еоЁ( реег ) ); 

24 ЕХТТ( О); 

25 } 


иарзоигсе. с 


10-14 Читаем из командной строки количество посылаемых датаграмм и их 
размер (второй параметр необязателен). Подготавливаем в переменной 
реехг ОЮР-сокет с адресом сервера. Вопреки совету 29 номер порта 
9000 жестко «зашит» в код. 

15-21 Посылаем указанное количество датаграмм серверу. 

22-23 Посылаем серверу последнюю датаграмму, содержащую нулевой байт. 
Для сервера она выполняет роль конца файла. 


Текст сервера в листинге 2.17 еще проще. 


Листинг 2.17. Приемник датаграмм 


царё1пк. с 
1 #1пс1аае "ееср.В" 
2 116 ма1п( 116 акос, спаг **агау ) 


3 { 

4 СОСКЕТ з; 

5 116 гс; 

6 106 аабаагатз = 0; 

7 11Е усураЕзх = 5000 * 1440; 
8 сПаг БоЕ[ 1440 }; 
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9 ТМТТ(); 
20 3 = ар зегуех( МЫ, "9000" }; 
11 зеёзоскор* ( $, $01 _ЗОСКЕТ, 50_ВСУВОЕ, 


12 ( спах * )&гсуБаЕз7, з12еоЁ( 1тё ) ); 
13 ео 
14 { 
15 гс = гесу( в, БаЕЁ, з12еоЁ( роаЁ ), 0); 
16 1Е (тс <= 0) 
17 ргеак; 
18 Чакадчгатз++; 
19 } 
20 еггог( 0, 0, "получено датаграмм: %Я \п", аабаагамз ); 
21 ЕХТТ (О); 
22 } 
иарэтркК. с 
10 Подготавливаем сервер к приему датаграмм из порта 9000 с любого ин- 
терфейса. 


11-12 Выделяем память для буфера на 5000 датаграмм длиной до 1440 байт. 


Примечание Здесь устанавливается размер буфера 7200000 байт, но нет га- 
рантии, что операционная система выделит столько памяти. 
Хост, работающий под управлением системы В5$), выделил бу- 
фер размером 41600 байт. Этим объясняется потеря дата- 
грамм, которая будет рассмотрена далее. 


13-19 Читаем и подсчитываем датаграммы, пока не придет пустая датаграм- 
ма или не произойдет ошибка. 
20 Выводим число полученных датаграмм на зе агегк. 


Источник и приемник на базе ТСР 


В совете 32 объясняется, что повысить производительность ТСР можно за 
счет выбора правильного размера буферов передачи и приема. Нужно установить 
размер буфера приема для сокета сервера и размер буфера передачи для сокета 
клиента. 

Поскольку в функциях Е ср_зегуег и Еср_с11еп используются размеры бу- 
феров по умолчанию, следует воспользоваться не библиотекой, а каркасами из сове- 
та 4. Сообщать ТСР размеры буферов нужно во время инициализации соедине- 
ния, ТО есть до вызова 11% еп в сервере и до вызова соппесе в клиенте. Поэтому 
невозможно воспользоваться функциями & ср_зегуег и 6 ср_с11епь, так как 
к моменту возврата из них обращение к 1156 еп или соппес® уже произошло. Нач- 
нем с клиента, его код приведен в листинге 2.18. 


Листинг 2.18. Функция тат ТСР-клиента, играющего роль источника 


Есрзоигсе.с 
1 1пЕ па1фп( 116 агдс, сваг **агау ) 
2 { 


81 |111 Основы 
3 зЕгасЕе зоскааахг_1п реек; 
4 сваг *ЮаЕ; 
5 СОСКЕТ $; 
6 1п6 с; 
Я 116 Р1Кз = 5000; 
8 106 зпараЁзи = 32 * 1024; 
9 116 эзп@аз7 = 1440; /* М№М$$ для ЕБПегпеЕ по умолчанию. */ 
10 ТМТТ(}; 
11 ореегг = 0; 
та \Н11е ( (с = деборе( агас, агкау, "з:Ъ:с:" ) ) != ЕОЕ } 
13 { 
14 эи1есй (с) 
15 { 
16 сазе "з" 
17 3па37 = або1( орвака ); 
18 Ьгеак; 
19 саве "Ъ" 
20 зпаБаЁв7 = або1( орвага ); 
21 Ьгеак; 
22 сазе "с" 
23 Ь1Кз = аЁо1( орвага ); 
24 Ъгеак; 
25 сазе "?" 
26 еггог( 1, 0, "некорректный параметр: %с\п", с ); 
27 } 
28 } 
28 1Е ( акас <= орелпа ) 
30 еггог( 1, 0, "не задано имя хоста\п" }; 
31 1Е ( (СЪ5Е = па]11ос( впаз7 ) ) == М ) 
32 еггог( 1, 0, "ошибка вызова ма1]ос\п" ); 


33 зее_аЯЯгез$ ( агау[ орё1та ], "9000", &реег, "Еср" 
34 3 = зосКеё( АЕ ТМЕТ, $ОСК_5ТВЕАМ, 0 ); 

35 1Е ( 1!13уа11ЯзосКк( з ) ) 

36 егког( 1, еггпо, "ошибка вызова зоскКее" }; 


37 1Е ( зеезосКоре( в, $0._ЗОСКЕТ, $0_$МОВИЕ, 


38 ( сваг * )&зпабаЕз7т, в12еоЁЕ( зэзпаБаЕзс ) ) ) 

39 еггог( 1, еггпо, "ошибка вызова зеезосКорЕ с опцией 
$0_5МОВОЕ" }; 

40 1Е ( соппесё( $, ( зЕкасЕ зоскаааг * )&реег, 

41 з317еоЁ( реек ) ) ) 

42 еггог( 1, еггпо, "ошибка вызова соппесё" ); 

43 \р11е( Ъ1К5-- > 0) 

44 зера( $, БаЁ, зпа$2, 0 ); 

45 ЕХТТ О); 

46 } 


ссрзоигсе. с 
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тат 


12-30 В цикле вызываем деборе для получения и обработки параметров из 


31-42 


командной строки. Поскольку эта программа будет использоваться и да- 
лее, то делаем ее конфигурируемой в большей степени, чем необходимо 
для данной задачи. С помощью параметров в командной строке можно 
задать размер буфера передачи сокета, количество данных, передавае- 
мых при каждой операции записи в сокет, и число операций записи. 
Это стандартный код инициализации ТСР-клиента, только добавлено 
еще обращение к зе зоскор® для установки размера буфера передачи, 
атакже с помощью функции па] 1ос выделен буфер запрошенного раз- 
мера для размещения данных, посылаемых при каждой операции запи- 
си. Обратите внимание, что инициализировать память, на которую 
указывает БцЕ, не надо, так как в данном случае безразлично, какие дан- 
ные посылать. 


43-44 Вызываем функцию зеп9 нужное число раз. 


Функция па1п сервера, показанная в листинге 2.19, взята из стандартного кар- 
каса с добавлением обращения к функции деЕорЕ для получения из командной 
строки параметра, задающего размер буфера приема сокета, а также вызов функ- 
ции деезоскоре для установки размера буфера. 


Листинг 2. 19. Функция тат ТСР-сервера, играющего роль приемника 


Е 
оюоючмиюоььн 


вв авеь - 
эиьъошън 


на + 
юЮо 


шо 
шьнто 


— 


Есре1пк.с 


пЕ мазп( 116 агдас, сВаг **ахкау ) 


зекисЕ зоскКаЯЯхг_1п 1оса1; 
зЕкисЕ зоскааЯхг_1п реек; 
106 реег1еп; 


ЗОСКЕТ $1; 
ЗОСКЕТ з; 
106 с; 
106 хсураЁзер = 32 * 1024; 
сопзЕ 116 оп = 1; 
ТМТ(); 
орбсегг = 0; 
\11е ( (с = деборе( ахкас, агаду, "Ь:" ) ) != ЕОЁ ) 
{ 
зитесв (с) 
{ 
сазе "Ъ" 
усУБаЁз2 = або1( орбага ); 
Ьгеак; 
сазе "?" 


еггог( 1, 0, "недопустимая опция: %с\п", с ); 


РЕСО ООО Основы 


24 зе _аЯагез$( МОГТ,, "9000", &1оса1, “"Еср" ); 
25 3 = зоскее( АЕ_ТМЕТ, $О0СК_$ТВЕАМ, 0); 

26 1ЁЕ ( 1!15уа11азосКк( ®з ) } 

27 егхгохг( 1, егхпо, "ошибка вызова зосКее" }; 


28 1Е ( зебзосКоре( $, $0ОГ._ЗОСКЕТ, $0_ВЕЧЗЕАТОВК, 
29 ( СсВаг * )&оп, з12еоЁ( оп ) } ) 
30 еггог( 1, еггпо, "ошибка вызова зебзоскорЕ 50_ВЕОЗЕАООВ" }; 


31 1Е ( зеЕзосКоре( в, $О0О._$ОСКЕТ, 50_ВСУВИЕ, 


32 ( сПак * )&гсУуБаЁз2, з1хеоЁ( гсураЁзс ) )} ) 

33 еггог( 1, еггпо, "ошибка вызова зебзосКорЕ $0_ВСУВОЕ" )}; 
34 1Е ( Рара( 3, ( зЕГасЕ зоскааагк * } &1оса1, 

35 3812е0оЁ( 1оса1 } } } 

36 ехгог( 1, екггпо, "ошибка вызова Блпа”" ); 

37 11эЕеп (3, 5}; 

38 Чо 

39 { 

40 реех]еп = $17еоЁ( реег ); 

41 $1 = ассере( $, ( зёгасЕ зоска@ааг * )&реег, &реег1еп ); 
42 1ЁЕ ( 1!13уа11азосКк( 31 ) ) 

43 егхог( 1, еггпо, "ошибка вызова ассерё" ); 

44 зегуег( 31, гсуБаЁз2 ); 

45 СЬО$ЗЕ( 81 }; 


46 } мр11е (0); 
47 ЕХТТ( О); 
48 } 
Есре1пк.с 


Функция зегуег читает и подсчитывает поступающие байты, пока не обнару- 
жит конец файла (совет 16) или не возникнет ошибка. Она выделяет память под 
буфер того же размера, что и буфер приема сокета, чтобы прочитать максимальное 
количество данных за одно обращение к гесу. Текст функции зегуег приведен 
в листинге 2.20. 


Листинг 2.20. Функция зегуег 


Есре1тк.с 
зЕаё1с \у01а зегуег( ЗОСКЕТ зв, 116 гсуБаЁв2 ) 
{ 


1 

2 

3 сраг *БаЕЁ; 

4 тие. те; 

5 1106 Рубез = 0; 
6 

7 

8 


1Е ( (БЕ = ма11ос( гсуБаЕзс ) } == ММ, ) 
еггог( 1, 0, "ошибка вызова па1]ос\п" )}; 
Ток”) 
9 { 
10 гс = гесу( 5, БаЕЁ, гсуБаЁЕз2, 0}; 
11 1Е (гс <=0 } 


12 ЬгеаКк; 
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13 Бусез += гс; 
14 } 
15 еггох( 0, 0, "получено байт: %Аа\п", русев ); 
16 } 
Есрэе1пкК.с 


Для измерения сравнительной производительности протоколов ТСР и ПОР 
при передаче больших объемов данных запустим клиента на машине Ъз9, а сер- 
вер — на 1оса1ПозЕ. Физически хосты Ъза 
и ]1оса]ТозЕ - это, конечно, одно и то же, но, 
как вы увидите, результаты работы программы 
в значительной степени зависят от того, какое 
из этих имен использовано. Сначала запустим Пользователь 
клиента и сервер на одной машине, чтобы оце- ППП” Ядро \ 777” о 
нить производительность ТСР и ОШР устра- 
нив влияние сети. В обоих случаях сегменты 
ТСР или датаграммы ОЧЮОР инкапсулируются 
в [Р-датаграммах и посылаются возвратному 
интерфейсу 100, который немедленно переправ- 
ляет их процедуре обработки [Р-входа, как пока- 
зано на рис. 2.17. 

Каждый тест был выполнен 50 раз с зада- 
ным размером датаграмм (в случае (ОР) или 
числом передаваемых за один раз байтов (в слу- 
чае ТСР), равным 1440. Эта величина вы- 
брана потому, что она близка к максимальному 
размеру сегмента, который ТСР может передать Рис. 2.17. Возвратный интерфейс 
по локальной сети на базе ЕЩегпей. 


Примечание Это число получается тах. В одном фрейме Ейете может быть 
передано не более 1500 байт. Каждый заголовок [Р и ТСР зани- 
мает 20 байт, так что остается 1460. Еще 20 байт резервиро- 
вано для опций ТСР. В системе В5О ТСР посылает 12 байт 
сопциями, поэтому в этом случае максимальный размер сегмен- 
та составляет 1448 байт. 


В табл. 2.2 приведены результаты, усредненные по 50 прогонам. Для каждого 
протокола указано три времени: по часам - время с момента запуска до завершения 
работы клиента; пользовательское —- проведенное программой в режиме пользова- 
теля; системное — проведенное программой в режиме ядра. В колонке «Мб/с» ука- 
зан результат деления общего числа посланных байтов на время по часам. В колонке 
«Потеряно» для (ОР приведено среднее число потерянных датаграмм. 

Первое, что бросается в глаза, — ТСР работает намного быстрее, когда в каче- 
стве имени сервера выбрано 1оса1НозЕ, анеЪза. Для ОПР это не так — заметной 
разницы в производительности нет. Чтобы понять, почему производительность 
ТСР так возрастает, когда клиент отправляет данные хосту 1оса1позЕ, запустим 


Основы 
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программу пеезсае (совет 38) с опцией -1. Здесь надо обратить внимание на две 
строки (ненужная информация опущена): 


Мапе Мец Месмиохк —Аадагезз 
еа0 1500 172.30 Ьза 
100 16384 127 ]1оса1ПозЕ 


Таблица 2.2. Сравнение производительности ТСР и ЦОР 
при количестве посылаемых байтов, равном 1440 


ТСР 

Сервер Время по часам Пользовательское Системное 
время время Мб/с 

Ь$а 2,88 0,0292 1,4198 25 
юсайо$ 0,9558 0,0096 0,6316 7,53 
зрагс 7,1882 0,016 16226 1,002 

ЧОР 
Сервер Время по часам Пользовательское Системное 

время время Мб/с Потеряно 

Ь$9 1,9618 0,0316 1,1934 3,67 336 
юса№о${ 1,9748 0,031 1,1906 3,646 272 
эрагс 5,8284 0,0564 0,844 1,235 440 


Как видите, максимальный размер передаваемого блока (МТУ — тахипит 
{гап$1115510п (0) для Ьза равен 1500, а для 1оса1ПозЕ - 16384. 


Примечание Такое поведение свойственно реализациям ТСР в системах, про- 
изводных от В5О. Например, в системе боап5 это уже не так. 
При первом построении маршрута к хосту Ъ39 в коде маршру- 
тизации предполагается, что хост находится в локальной сети, 
поскольку сетевая часть [Р-адреса совпадает с адресом интер- 
фейса Ейетее. И лишь при первом использовании маршрута ТСР 
обнаруживает, что он ведет на тот же хост и переключается 
на возвратный интерфейс. Однако к этому моменту все метри- 
ки маршрута, в том числе и МТО, уже установлены в соответ- 
ствии с интерфейсом к локальной сети. 


Это означает, что при посылке данных на 1оса1НозЕ ТСР может отправлять 
сегменты длиной до 16384 байт (или 16384 - 20 -— 20 - 12 = 16332 байт). Однако 
при посылке данных на хост Ъз@ число байт в сегменте не превышает 1448 (как 
было сказано выше). Но чем больше размер сегментов, тем меньшее их количество 
приходится посылать, а это значит, что требуется меньший объем обработки, и со- 
ответственно снижаются накладные расходы на добавление к каждому сегменту за- 
головков [Ри ТСР А результат налицо — обмен данными с хостом 1оса1позЕ проис- 
ходит в три раза быстрее, чем с хостом Ъза. 
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Можно заметить, что на хосте 1оса1позЕ ТСР работает примерно в два раза 
быстрее, чем ОШР. Это также связано с тем, что ТСР способен объединять несколь- 
ко блоков по 1440 байт в один сегмент, тогда как ОЮР посылает отдельно каждую 
датаграмму длиной 1440 байт. 

Следует отметить, что в локальной сети ОЮР примерно на 20% быстрее ТСР, 
но потеря датаграмм значительнее. Потери имеют место даже тогда, когда и сер- 
вер, и клиент работают на одной машине; связаны они с исчерпанием буферов. 
Хотя передача 5000 датаграмм на максимально возможной скорости - это скорее 
отклонение, чем нормальный режим работы, но все же следует иметь в виду воз- 
можность такого результата. Это означает, что (ОР не дает никакой гарантии от- 
носительно доставки данной датаграммы, даже если оба приложения работают на 
одной машине. 

По результатам сравнения сеансов с хостами 1оса11оз® и Ъза можно пред- 
положить, что на производительность влияет также длина посылаемых датаграмм. 
Например, если прогнать те же тесты с блоком длиной 300 байт, то, как следует из 
табл. 2.3, ТСР работает быстрее ОПР и на одной машине, и в локальной сети. 

Из этих примеров следует важный вывод: нельзя строить априорные предпо- 
ложения о сравнительной производительности ТСР и ОБР При изменении усло- 
вий, даже очень незначительном, показатели производительности могут очень 
резко измениться. Для обоснованного выбора протокола лучше сравнить их про- 
изводительность на контрольной задаче (совет 8). Когда это неосуществимо на 
практике, все же можно написать небольшие тестовые программы для получения 
хотя бы приблизительного представления о том, чего можно ожидать. 


Таблица. 2.3. Сравнение производительности ТСР и ЦОР 
при количестве посылаемых байтов, равном 300 


ТСР 

Сервер Время по часам Пользовательское Системное 
время время Мб/с 

Ба 1,059 0,0124 0,445 1,416 
зрагс 1,5552 0,0084 1,2442 0,965 

ЧОР 
Сервер Время по часам Пользовательское Системное 

время время Мб/с Потеряно 

Ба 1,6324 0,0324 0,9998 0,919 212 
зрагс 1,9118 0,0278 1,4352 0,785 306 


Если говорить о практической стороне вопроса, то современные реализации 
ТСР досгаточно эффективны. Реально продемонстрировано, что ТСР может ра- 
ботать со скоростью аппаратуры на стомегабитных сетях ЕОПТ. В недавних экс- 
периментах были достигнуты почти гигабитные скорости при работе на персо- 
нальном компьютере [СаПайп ее а|. 1999]. 
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Примечание 29 июля 1999 года исследователи из Университета Дьюка на ра- 
бочей станции ХР1О00 производства РЕС/Сотрад на базе процес- 
сора Ара в сети Муппее получили скорости передачи порядка ги- 
габита в секунду. В экспериментах использовался стандартный 
стек ТСР/ТР из системы ЕтееВ5Л 4.0, модифицированный по 
технологии сокетов без копирования (гето-сору 5осЁеёз). В том 
же эксперименте была получена скорость более 800 Мбит/с на 
персональном компьютере РИ 450 М и более ранней версии 
сети МуппеЕ. Подробности можно прочитать на \ЕЬ-страниице 


Вир /шилос.диКе.еди/ап/Дтареге. 


Резюме 


ОР не всегда быстрее, чем ТСР. На сравнительную производительность обо- 
их протоколов влияют разные факторы, и для каждого конкретного случая жела- 
тельно проверять быстродействие на контрольных задачах. 


Совет 8. Не надо заново изобретать ТСР 


Как сказано в совете 7, (ЮР может быть намного производительнее ТСР 
в простых приложениях, где есть один запрос и один ответ. Это наводит на мысль 
использовать в транзакционных задачах такого рода именно ОПР Однако прото- 
кол ОПР не слишком надежен, поэтому эта обязанность лежит на приложении. 

Как минимум, это означает, что приложение должно позаботиться о тех дата- 
граммах, которые теряются или искажаются при передаче. Многие начинающие се- 
тевые программисты полагают, что при работе в локальной сети такая возможность 
маловероятна, и потому полностью игнорируют ее. Но в совете 7 было показано, как 
легко можно потерять датаграммы даже тогда, когда клиент и север находятся на 
одной машине. Поэтому не следует забывать о защите от потери датаграмм. 

Если же приложение будет работать в глобальной сети, то также возможен 
приход датаграмм не по порядку. Это происходит, когда между отправителем 
и получателем было несколько маршрутов. 

В свете вышесказанного можно утверждать, что любое достаточно устойчивое 
ООР-приложение должно обеспечивать: 


О повторную посылку запроса, если ответ не поступил в течение разумного 
промежутка времени; 
О проверку соответствия между ответами и запросами. 


Первое требование можно удовлетворить, если при посылке каждого запроса 
взводить таймер, называемый таймером ретрансмиссии (гегапзтз1оп &итег), или 
ВТО-таймером. Если таймер срабатывает до получения ответа, то запрос посыла- 
ется повторно. В совете 20 будет рассмотрено несколько способов эффективного 
решения этой задачи. Второе требование легко реализуется, если в каждый запрос 
включить его порядковый номер и обеспечить возврат этого номера сервером вме- 
сте с ответом. 
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Если приложение будет работать в Иуегпе, то фиксированное время сраба- 
тывания КТО-таймера не годится, поскольку период кругового обращения (ВТТ) 
между двумя хостами может существенно меняться даже за короткий промежуток 
времени. Поэтому хотелось бы корректировать значение ВКТО-таймера в зависи- 
мости от условий в сети. Кроме того, если КТО-таймер срабатывает, следует уве- 
личить его продолжительность перед повторной передачей, поскольку она, скорее 
всего, была слишком мала. Это требует некоторой экспоненциальной корректиров- 
ки (ехропепиа| Баской) КТО при повторных передачах. 

Далее, если приложение реализует что-либо большее, чем простой протокол 
запрос-ответ, когда клиент посылает запрос и ждет ответа, не посылая дополни- 
тельных датаграмм, или ответ сервера состоит из нескольких датаграмм, то необ- 
ходим какой-то механизм управления потоком. Например, если сервер - это при- 
ложение, работающее с базой данных о кадрах, а клиент просит послать имена 
и адреса всех сотрудников конструкторского отдела, то ответ будет состоять из не- 
скольких записей, каждая из которых посылается в виде отдельной датаграммы. 
Если управление потоком отсутствует, то при этом может быть исчерпан пул бу- 
феров клиента. Обычный способ решения этой проблемы - скользящее окно типа 
того, что используется в ТСР (только подсчитываются не байты, а датаграммы). 

И, наконец, если приложение передает подряд несколько датаграмм, необхо- 
димо позаботиться об управлении перегрузкой. В противном случае такое прило- 
жение может легко стать причиной деградации пропускной способности, которая 
затронет всех пользователей сети. 

Все перечисленные действия, которые должно предпринять основанное на 
протоколе ОПР приложение для обеспечения надежности, - это, по сути, вариант 
ТСР. Иногда на это приходится идти. Ведь существуют транзакционные прило- 
жения, в которых накладные расходы, связанные с установлением и разрывом 
'ТСР-соединения, близки или даже превышают затраты на передачу данных. 


Примечание Обычный пример — это система доменных имен (ротат Мате 
бует — РМ№5), которая используется для отображения домен- 
ного имени хоста на его 1Р-адрес. Когда вводится имя хоста 
или. гЕс-еа1вог.ога в Иеб-браузере, реализованный внутри 
браузера клиент ОМ5 посылает ОМ5-серверу ИОР-датаграмму 
с запросом [Р-адреса, ассоциированного с этим именем. Сервер 
в ответ посылает датаграмму, содержащую [Р-адрес 128.9.160.27. 
Подробнее система ОМ№5 обсуждается в совете 29. 


Тем не менее необходимо тщательно изучить природу приложения, чтобы по- 
нять, стоит ли заново реализовывать ТСР. Если приложению требуется надеж- 
ность ТСР, то, быть может, правильное решение - это использование ТСР. 

Маловероятно, что функциональность ТСР, продублированная на приклад- 
ном уровне, будет реализована столь же эффективно, как в настоящем ТСР. Отча- 
сти это связано с тем, что реализации ТСР - это плод многочисленных экспери- 
ментов и научных исследований. С годами ТСР эволюционировал по мере того, 
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как публиковались наблюдения за его работой в различных условиях и сетях, 
в том числе и Ицегпей. 

Кроме того, ТСР почти всегда исполняется в контексте ядра. Чтобы понять, 
почему это может повлиять на производительность, представьте себе, что проис- 
ходит при срабатывании В/ТО-таймера в вашем приложении. Сначала ядру нужно 
«пробудить» приложение, для чего необходимо контекстное переключение из ре- 
жима ядра в режим пользователя. Затем приложение должно послать данные. Для 
этого требуется еще одно контекстное переключение (на этот раз в режим ядра), 
в ходе которого данные из датаграммы копируются в буферы ядра. Ядро выбирает 
маршрут следования датаграммы, передает ее подходящему сетевому интерфей- 
су и возвращает управление приложению - снова контекстное переключение. 
Приложение должно заново взвести КТО-таймер, для чего приходится вновь пе- 
реключаться. 

А теперь обсудим, что происходит при срабатывании КТО-таймера внутри 
ТСР. У ядра уже есть сохраненная копия данных, нет необходимости повторно ко- 
пировать их из пространства пользователя. Не нужны и контекстные переключе- 
ния. ТСР заново посылает данные. Основная работа связана с передачей данных 
из буферов ядра сетевому интерфейсу. Повторные вычисления не требуются, так 
как ТСР сохранил всю информацию в кэше. 

Еще одна причина, по которой следует избегать дублирования функциональ- 
ности ТСР на прикладном уровне, — потеря ответа сервера. Поскольку клиент не 
получил ответа, у него срабатывает таймер, и он посылает запрос повторно. При 
этом сервер должен дважды обработать один и тот же запрос, что может быть не- 
желательно. Представьте клиент, который «просит» сервер перевести деньги с одно- 
го банковского счета на другой. При использовании ТСР логика повторных попыток 
реализована вне приложения, так что сервер вообще не определит, повторный ли это 
запрос. 


Примечание Здесь не рассматривается возможность сетевого сбоя или отка- 
за одного из хостов. Подробнее это рассматривается в совете 9. 


Транзакционные приложения и некоторые проблемы, связанные с применени- 
ем в них протоколов ТСР и ОР обсуждаются в ВЕС 955 [Вга4деп 1985]. В этой 
работе автор отстаивает необходимость промежуточного протокола между нена- 
дежным, но не требующим соединений ОПР и надежным, но зависящим от соеди- 
нений ТСР, Соображения, изложенные в этом ВЕС, легли в основу предложенного 
Брейденом протокола ТСР Ежепз!опз юг Тгапзасйопз (Т/ТСР), который рассмот- 
рен ниже. 

Один из способов обеспечить надежность ТСР без установления соединения — 
воспользоваться протоколом Т/ТСР. Это расширение ТСР, позволяющее достичь для 
транзакций производительности, сравнимой с ОПР за счет отказа (как правило) от 
процедуры трехстороннего квитирования в ходе установления обычного ТСР-соеди- 
нения и сокращения фазы ТТМЕ-\УМАТТ (совет 22) при разрыве соединения. 

Обоснование необходимости Т/ТСР и идеи, лежащие в основе его реализации, опи 
саны в ВЕС 1379 [Вгадеп 1992а]. ВЕС 1644 [Вгадеп 1994] содержит функциональнук, 
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спецификацию Т/ТСР а также обсуждение некоторых вопросов реализации 
В работе [З{еуеп$ 1996] рассматривается протокол Т/ТСР приводятся сравнение 
его производительности с ДОР изменения в АР! сокетов, необходимые для под- 
держки нового протокола, и его реализация в системе 4.4В$ О. 

К сожалению, протокол Т/ТСР не так широко распространен, хотя и реализо- 
ван в ЕгееВЗО, и существуют дополнения к ядру Гпих 2.0.32 и 5ипО$ 4.1.3. 

Ричард Стивенс ведет страницу, посвященную Т/ТСР, на которой есть ссыл- 
ки на различные посвященные этому протоколу ресурсы. Адрес \’еБ-страницы — 


Беер: / Илим КоБа[а. сот /збаге/ ср, Бет]. 


Резюме 


Здесь рассмотрены шаги, необходимые для построения надежного протокола 
поверх ОШОР. Хотя и существуют приложения, например, ОМ, в которых это сде- 
лано, но для корректного решения такой задачи необходимо практически заново 
реализовать ТСР. Поскольку маловероятно, что реализованный на базе (ЮР про- 
токол будет так же эффективен, как ТСР, смысла в этом, как правило, нет. 

В этом разделе также кратко обсуждается протокол Т/ТСР - модификация 
ТСР для оптимизации транзакционных приложений. Хотя Т/ТСР решает многие 
проблемы, возникающие при использовании ТСР для реализации транзакций, он 
пока не получил широкого распространения. 


Совет 9. При всей надежности у ТСР есть 
и недостатки 


Как уже неоднократно отмечалось, ТСР -— надежный протокол. Иногда эту 
мысль выражают так: «ТСР гарантирует доставку отправленных данных». Хотя эта 
формулировка часто встречается, ее следует признать исключительно неудачной. 

Предположим, что вы отсоединили хост от сети в середине передачи данных. 
В таком случае ТСР не сможет доставить оставшиеся данные А на практике про- 
исходят сбои в сети, аварии серверов, выключение машины пользователями без 
разрыва ТСР-соединения. Все это мешает ТСР доставить по назначению данные, 
переданные приложением. 

Но еще важнее психологическое воздействие фразы о «гарантируемой ТСР 
доставке» на излишне доверчивых сетевых программистов. Разумеется, никто не 
считает, что ТСР обладает магической способностью доставлять данные получа- 
телю, невзирая на все препятствия. Вера в гарантированную доставку проявляет- 
ся в небрежном программировании и, в частности, в легкомысленном отношении 
к проверке ошибок. 


Что такое надежность 


Прежде чем приступать к рассмотрению ошибок, с которыми можно столк- 
нуться при работе с ТСР, обсудим, что понимается под надежностью ТСР. Если 
ТСР не гарантирует доставку всех данных, то что же он гарантирует? Первый во- 
прос: кому дается гарантия? На рис. 2.18 показан поток данных от приложения А вниз 
к стеку ТСР/Р на хосте А, через несколько промежуточных маршрутизаторов, 
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вверх к стеку ТСР/1Р на хосте В и, наконец, к приложению В. Когда ТСР-сегмент 
покидает уровень ТСР на хосте А, он «обертывается» в 1Р-датаграмму для переда- 
чи хосту на другой стороне. По пути он может пройти через несколько маршрути- 
заторов, но, как видно из рис. 2.18, маршрутизаторы не имеют уровня "ТСР, они 


лишь переправляют [Р-датаграммы. 
Пользователь 


ТСР 


Интерфейс 


ТСР 


Интерфейс 


Интерфейс 


Рис. 2.18. Сеть с промежуточными маршрутизаторами 


Примечание Некоторые маршрутизаторы в действительности могут пред- 
ставлять собой компьютеры общего назначения, у которых 
есть полный стек ТСР/ТР, но и в этом случае при выполнении 
функций маршрутизации не задействуются ни уровень ТСР, ни 
прикладной уровень. 


Поскольку известно, что протокол 1Р ненадежен, то первое место в тракте про- 
хождения данных, в связи с которым имеет смысл говорить о гарантиях, - это уро- 
вень ТСР хоста В. Когда сегмент оказывается на этом уровне, единственное, что 
можно сказать наверняка, - сегмент действительно прибыл. Он может быть запор- 
чен, оказаться дубликатом, прийти не по порядку или оказаться неприемлемым 
еще по каким-то причинам. Обратите внимание, что отправляющий 'ТСР не может 
дать никаких гарантий по поводу сегментов, доставленных принимающему ТСР. 

Однако принимающий ТСР уже готов кое-что гарантировать отправляющему 
ТСР, а именно — любые данные, которые он подтвердил с помощью сегмента АСК, 
а также все предшествующие данные, корректно дошли до уровня ТСР. Поэтому 
отправляющий 'ТСР может отбросить их копии, которые у него хранятся. Это не 
означает, что информация уже доставлена приложению или будет доставлена в бу- 
дущем. Например, принимающий хост может аварийно остановиться сразу после 
посылки АСК, еще до того, как данные прочитаны приложением. Это стоит под- 
черкнуть особо: единственное подтверждение приема данных, которое находится 
в ведении ТСР, - это вышеупомянутый сегмент АСК. Отправляющее приложение 
не может, полагаясь только на ТСР, утверждать, что данные были благополучно 
прочитаны получателем. Как будет сказано далее, это одна из возможных ошибок 
при работе с ТСР, о которых разработчик должен знать. 
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Второе место, в связи с которым имеет смысл говорить о гарантиях, — это само 
приложение В. Вы поняли, нет гарантий, что все данные, отправленные приложе- 
нием А, дойдут до приложения В. Единственное, что ТСР гарантирует приложе- 
нию В, -доставленные данные пришли в правильном порядке и не испорчены. 


Примечание Неискаженность данных гарантируется лишь тем, что ошиб- 
ку можно обнаружить с помощью контрольной суммы. Посколь- 
ку эта сумма представляет собой 16-разрядное дополнение до 
единицы суммы двойных байтов, то она способна обнаружить 
пакет ошибок в 15 бит или менее [Риттет 1978]. Предполагая 
равномерное распределение данных, вероятность принятия 
ТСР ошибочного сегмента за правильный составляет не более 
1/ (2-1). Однако в работе [50пе еЁ а. 1998] показано, что 
в реальных данных, встречающихся в сегментах ТСР, частота 
ошибок, не обнаруживаемых с помощью контрольной суммы, 
при некоторых обстоятельствах может быть намного выше. 


Потенциальные ошибки 


Вы уже видели одну из потенциальных ошибок при работе с ТСР: не исклю- 
чено, что подтвержденные ТСР данные не дошли до приложения-получателя. Как 
и большинство других таких ошибок, это довольно редкая ситуация, и, даже если 
она встречается, последствия могут быть не очень печальными. Важно, чтобы про- 
граммист знал об этой неприятности и предусматривал защиту при возможном 
нежелательном результате. Не думайте, что ТСР обо всем позаботится сам, следу- 
ет подумать об устойчивости приложения. 

Защита от упомянутой ошибки очевидна. Если приложению-отправителю важ- 
но иметь информацию, что сообщение дошло до приложения-получателя, то по- 
лучатель должен сам подтвердить факт приема. Часто такое подтверждение при- 
сутствует неявно. Например, если клиент запрашивает у сервера некоторые данные 
и сервер отвечает, то сам ответ - это подтверждение получения запроса. Один из воз- 
можных способов организации явных подтверждений обсуждается в совете 19. 

Более сложный для клиента вопрос - что делать, если сервер не подтверждает 
приема? Это в основном зависит от конкретного приложения, поэтому готового 
решения не существует. Однако стоит отметить, что повторная посылка запроса 
не всегда годится; как говорилось в совете 8, вряд ли будет правильно дважды пе- 
реводить одну сумму со счета на счет. В системах управления базами данных для 
решения такого рода проблем применяется протокол трехфазной фиксации. По- 
добный подход приемлем и для других приложений, гарантирующих, что опера- 
ция выполняется «не более одного раза». Один из примеров — службы параллель- 
ности, фиксации и восстановления (сопсиггепсу, сот тей, гесоуегу — ССК) - это 
элемент прикладного сервиса в протоколах ОЗТ. Протокол ССК обсуждается в ра- 
боте []а11 апа Авгамаа 1993]. 

ТСР - протокол сквозной передачи (еп -{юо-еп4 ргоюсо]), то есть он стремит- 
ся обеспечить надежный транспортный механизм между двумя хостами одного 
ранга. Важно, однако, понимать, что конечные точки - это уровни ТСР на обоих 
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хостах, а не приложения. Программы, которым нужны подтверждения на приклад- 
ном уровне, должны самостоятельно это определить. 

Рассмотрим некоторые типичные ошибки. Пока между двумя хостами суще- 
ствует связь, ТСР гарантирует доставку данных по порядку и без искажений. 
Ошибка может произойти только при разрыве связи. Из-за чего же связь может 
разорваться? Есть три причины: 


О постоянный или временный сбой в сети; 
О отказ принимающего приложения; 
О аварийный сбой самого хоста на принимающем конце. 


Каждое из этих событий по-разному отражается на приложении-отправителе. 


Сбой в сети 


Сбои в сети происходят по разным причинам: от потери связи с маршрутиза- 
тором или отрезком опорной сети до выдергивания из разъема кабеля локальнои 
Еегпе-сети. Сбои, происходящие вне оконечных точек, обычно временные, по- 
скольку протоколы маршрутизации спроектированы так, чтобы обнаруживать по- 
врежденные участки и обходить их. 


Примечание Под оконечной точкой понимается локальная сеть или хост, на 
котором работает приложение. 


Если же ошибка возникает в оконечной точке, то неисправность будет суще- 
ствовать, пока ее не устранят. 

Если промежуточный маршрутизатор не посылает {СМР-сообщение о том, что 
хост или сеть назначения недоступны, то ни само приложение, ни стек ТСР/Р на 
том же хосте не смогут немедленно узнать о сбое в сети (совет 10). В этом случае 
у отправителя через некоторое время возникнет тайм-аут, и он повторно отправит 
неподтвержденные сегменты. Это будет продолжаться, пока отправляющий ТСР 
не признает доставку невозможной, после чего он обрывает соединение и сообща- 
ет об ошибке. В системе В$О это произойдет после 12 безуспешных попыток 
(примерно 9 мин). При наличии у ТСР ожидающего запроса на чтение операция 
возвращает ошибку, и переменная еггпо устанавливается в ЕТТМЕРООТ. Если 
ожидающего запроса на чтение нет, то следующая операция записи завершится 
ошибкой. При этом либо будет послан сигнал ЗТСРТРЕ, либо (если этот сигнал 
перехвачен или игнорируется) в переменную еггпо записано значение ЕРТРЕ. 

Если промежуточный маршрутизатор не может переправить далее 1Р-датаграмму, 
содержащую некоторый сегмент, то он посылает хосту-отправителю {СМР-сообще- 
ние о том, что сеть или хост назначения недоступны. В этом случае некоторые реали- 
зации возвращают в качестве кода ошибки значение ЕМЕТОМВЕАСН или ЕНОЗТОМВЕАСН. 


Отказ приложения 


А теперь разберемся, что происходит, когда аварийно или как-либо иначе за- 
вершается приложение на другом конце соединения. Прежде всего следует пони- 
мать, что с точки зрения вашего приложения аварийное завершение другого конца 
не отличается от ситуации, когда приложение на том конце вызывает функцию 
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с1озе (или с1озезоскКек, если речь идет о УЛп4о\°), а затем ех1е. В обоих слу- 
чаях ТСР на другом конце посылает вашему ТСР сегмент ЕПМ. ЕГМ выступает в роли 
признака конца файла и означает, что у отправившего его приложения нет больше 
данных для вас. Это не значит, что приложение на другом конце завершилось или 
не хочет принимать данные. Подробнее это рассмотрено в совете 16. Как прило- 
жение уведомляется о приходе ЕТМ (и уведомляется ли вообще), зависит от его 
действий в этот момент. Для проработки возможных ситуаций напишем неболь- 
шую клиентскую программу, которая читает строку из стандартного входа, посы- 
лает ее серверу, читает ответ сервера и записывает его на стандартный выход. Ис- 
ходный текст клиента приведен в листинге 2.21. 


Листинг 2.21. ТСР-клиент, который читает и выводит строки 


Еерги.с 

1 #10пс1аае "ебср.п" 

2 116 ма1п( 116 агас, срахг **агау } 

3 { 

4 ЗОСКЕТ $; 

5 116 гс; 

6 106 1еп; 

7 спаг рРаЕЁ|[ 120 ]; 

8 ТМЕТ(); 

9 3 = Сср с11ерё( агау[ 1 ], ахау[ 2 ] ); 

10 ий11е ( Едеёз( РаЁ, з12еоЕЁ( БаЁ }, зап ) != МОШ ) 
11 { 

12 1еп = зсу1еп( БЕ ); 

13 ГС = зепа( зв, БЕ, 1еп, 0); 

14 1Е (ус < 0) 

15 еугог( 1, еггпо, "ошибка вызова зеп@а" ); 

16 гс = геаЯ11пе( з, БаЕЁ, 5$12еоЁ( БЕ ) }; 

17 1Е (ус < 0) 

18 еггог( 1, егхгпо, "ошибка вызова геаЯ]11те" }; 
19 е1зе 1ЕЁ (тс == } 
20 еггохг( 1, 0, "сервер завершил работу\п" ); 
21 е1зе 
22 Ерчбз( БаЕ, зЕаочце ); 
23 } 

24 ЕХТТ (О); 

ды. 2 

Еоерги.с 


8-9 Инициализируем приложение как ТСР-клиент и соединяемся с ука- 
занными в командной строке сервером и портом. 

10-15 Читаем строки из стандартного входа и посылаем их серверу, пока не 
встретится конец файла. 

16-20 После отправки данных серверу читается строка ответа. Функция 
геа91 1пе получает строку, считывая данные из сокета до символа новой 
строки. Текст этой функции приведен в листинге 2.32 в совете 11. Если 
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хеа911пе обнаруживает ошибку или возвращает признак конца файла 
(совет 16), то печатаем диагностическое сообщение и завершаем работу. 
22 В противном случае выводим строку на Е аоче. 


Для тестирования клиента напишем сервер, который читает в цикле строки, 


поступающие от клиента, и возвращает сообщения о количестве полученных 
строк. Для имитации задержки между приемом сообщения и отправкой ответа сер- 
вер пять секунд «спит». Код сервера приведен в листинге 2.22. 


Листинг 2.22. Сервер, подсчитывающий сообщения 


соипЕ. с 

1 Нис1аае "ебср.В" 

2 1пЕ пмазп( 2106 агдс, срах **ахгду ) 

— { 

4 ЗОСКЕТ 3; 

5 СОСКЕТ 31; 

6 116 гс; 

7 106 1еп; 

8 106 социЕег = 1; 

9 страх БаЕ[ 120 |; 
10 ТО 

11 $ = Еср_зекуег( МОШ,, акду[ 1] }); 
12 31 = ассере( зв, МОБ, М ); 

13 1ЁЕ ( !1зуа11азосКк( 1 )} ) 

14 еггог( 1, еггпо, "ошибка вызова ассере" }; 

15 \р11е ( ( гс = геа@Я111пе( 1, БаЁ, $12еоЁ( БаЁ ) ) })} >20) 
16 { 

17 51еер( 5 ); 

18 1еп = эре1аЕЕ( БаЁ, "получено сообщение %Я\п", соипбег++ ); 
19 гс = зепа( 1, БаЕЁ, 1еп, 0 }; 
20 1Е (кс < 0) 
21 еггохг( 1, еггпо, "ошибка вызова зепа" }; 
22 } 
я Ех 0); 
24 } 

СОЧПЁ. С 


Чтобы увидеть, что происходит при крахе сервера, сначала запустим сервер 


и клиент в различных окнах на машине Ъза. 


Ьза: $ Есрки 1оса1Вове 9000 

Ве11о 

получено сообщение 1 Это печатается после пятисекундной задержки. 
Здесь сервер был остановлен. 

Ве11о ада1п 

Есрги; ошибка вызова геа@11пе: Соппес&1оп гезее Бу реег (54) 

Ьза: $ 


Серверу посылается одно сообщение, и через 5 с приходит ожидаемый ответ. 


Останавливаете серверный процесс, моделируя аварийный отказ. На стороне 
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клиента ничего не происходит. Клиент блокирован в вызове Едеез, а протокол 
ТСР не может передать клиенту информацию о том, что от другого конца получен 
конец файла (ЕГХ). Если ничего не делать, то клиент так и останется блокирован- 
ным в ожидании ввода и не узнает о завершении сеанса сервера. 

Затем вводите новую строку. Клиент немедленно завершает работу с сообще- 
нием о том, что хост сервера сбросил соединение. Вот что произошло: функция 
Гдеез вернула управление клиенту, которому все еще неизвестно о приходе при- 
знака конца файла от сервера. Поскольку ничто не мешает приложению посылать 
данные после прихода ЕП\, ТСР клиента попытался послать серверу вторую стро- 
ку. Когда ТСР сервера получил эту строку, он послал в ответ сегмент В$Т (сброс), 
поскольку соединения уже не существует, — сервер завершил сеанс. Когда клиент 
вызывает геаЯ] 1 пе, ядро возвращает ему код ошибки ЕСОММВЕЗЕТ, сообщая тем 
самым о получении извещения о сбросе. На рис. 2.19 показана хронологическая 
последовательность этих событий. 


Клиент Сервер 


5-я 
секунда 


"Получено 
е 


общени 
ое Сервер 
остановлен 


“Вес адат ” 


Рис. 2.19 
Хронологическая последовательность 
событий при крахе сервера 


Клиент 
завершает 
сеанс 


А теперь рассмотрим ситуацию, когда сервер «падает», не успев закончить об- 
работку запроса и ответить. Снова запустите сервер и клиент в разных окнах на 
машине Ъза. 


рза: $ верхи 1оса1рове 9000 
Ве11о 
Здесь сервер был остановлен. 
Ссрги: сервер завершил работу 
рва: $ 


Посылаете строку серверу, а затем прерываете его работу до завершения вызова 
з1еер. Тем самым имитируется крах сервера до завершения обработки запроса. На 
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этот раз клиент немедленно получает сообщение об ошибке, говорящее о завершении 
сервера. В этом примере клиент в момент прихода ЕПМ блокирован в вызове геа@а1 1пе 
и ТСР может уведомить геаа1 {пе сразу, как только будет получен конец фай- 
ла. Хронологическая последовательность этих событий изображена на рис. 2.20. 


Клиент Сервер 
"Бео” 
Сервер 


остановлен рис, 2.20 
Крах сервера в момент, 


Клиент когда в клиенте происходит 
завершает 


Ошибка также может произойти, если игнорировать извещение о сбросе со- 
единения и продолжать посылать данные. Чтобы промоделировать эту ситуацию, 
следует изменить обращение к функции еггог после геа911пе - вывести диа- 
гностическое сообщение, но не завершаться. Для этого достаточно вместо строки 
17 в листинге 2.21 написать 


еггог( 0, еггпо, "ошибка при вызове геа@а11пе" }; 
Теперь еще раз надо прогнать тест: 


Ьза: $ варки Тоса1Ъове 9000 

Ве11о 

получено сообщение 1 
Здесь сервер был остановлен. 

Ве11о ада1п 

Есрги: ошибка вызова геаа11пе: Соппесе1оп гезеЕ Бу реег (54) 
Клиент игнорирует ошибку, но 
ТСР уже разорвал соединение, 

Ве11о Еох Ве 1авё &1ще 

Вгокеп р1ре Клиент получает сигнал 5ТСРТРЕ 


и заверщает работу. 
Ьза: $ 


Когда вводится вторая строка, клиент, как и раньше, немедленно извещает об 
ошибке (соединение сброшено сервером), но не завершает сеанс. Он еще раз об- 
ращается к Ёдефз, чтобы получить очередную строку для отправки серверу. Но 
стоит внести эту строку, как клиент тут же прекращает работу, и командный ин- 
терпретатор сообщает, что выполнение было прервано сигналом ЗТСРТРЕ. В этом 
случае при втором обращении к зепа, как и прежде, ТСР послал В$Т, но вы не 
обратили на него внимания. Однако после получения В5Т клиентский ТСР ра- 
зорвал соединение, поэтому при попытке отправить третью строку он немедлен- 
но завершает клиента, посылая ему сигнал 5ТСРТРЕ. Хронология такая же, как 
на рис. 2.19. Разница лишь в том, что клиент «падает» при попытке записи, а не 
чтения. 
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Правильно спроектированное приложение, конечно, не игнорирует ошибки, 
но Такая ситуация может иметь место и в корректно написанных программах. 
Предположим, что приложение выполняет подряд несколько операций записи без 
промежуточного чтения. Типичный пример — ЕТР. Если приложение на другом 
конце «падает», то ТСР посылает сегмент Е[М. Поскольку данная программа толь- 
ко пишет, но не читает, в ней не содержится информация о получении этого ЕПМ. 
При отправке следующего сегмента ТСР на другом конце вернет ВТ. А в про- 
грамме опять не будет никаких сведений об этом, так как ожидающей операции 
чтения нет. При второй попытке записи после краха отвечающего конца про- 
грамма получит сигнал 5ТСРТРЕ, если этот сигнал перехвачен или игнорирует- 
ся — код ошибки ЕРТРЕ. 

Такое поведение вполне типично для приложений, выполняющих многократ- 
ную запись без чтения, поэтому надо отчетливо представлять себе последствия. 
Приложение уведомляется только после второй операции отправки данных завер- 
шившемуся партнеру. Но, так как предшествующая операция привела к сбросу 
соединения, посланные ей данные были потеряны. 

Поведение зависит от соотношения времен. Например, если снова прогнать 
первый тест, запустив сервер на машине зрагс, а клиента — на машине Ъза, то по- 
лучается следующее: 


Ьза: $ Есргм Тоса1Вове 9000 

Ве11о 

получено сообщение 1 Это печатается после пятисекундной 
задержки. 
Здесь сервер был остановлен. 

Ве11о ада1п 

Есрги: сервер завершил работу 

за: $ 


На этот раз клиент обнаружил конец файла, посланный в результате останов- 
ки сервера. ВЗТ по-прежнему генерируется при отправке второй строки, но из-за 
задержек в сети клиент успевает вызвать геаЯ11пе и обнаружить конец файла 
еще до того, как хост Ъза получит В$Т. Если вставить между строками 14 и 15 
в листинге 2.21 строчку 


$1еер( 1 ); 


с целью имитировать обработку на клиенте или загруженность системы, то полу- 
чится тот же результат, что и при запуске клиента и сервера на одной машине. 


Крах хоста на другом конце соединения 


И последняя ошибка, которую следует рассмотреть, - это аварийный останов 
хоста на другом конце. Ситуация отличается от краха хоста, поскольку ТСР на 
другом конце не может с помощью сегмента ЕТМ проинформировать программу 
о том, что ее партнер уже не работает. 

Пока хост на другом конце не перезагрузят, ситуация будет выглядеть как 
сбой в сети — ТСР удаленного хоста не отвечает. Как и при сбое в сети, ТСР про- 
должает повторно передавать неподтвержденные сегменты. Но в конце концов, 
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если удаленный хост так и не перезагрузится, то ТСР вернет приложению код 
ошибки ЕТТМЕРОЧТ. 

А что произойдет, если удаленный хост перезагрузится до того, как ТСР пре- 
кратит попытки и разорвет соединение? Тогда повторно передаваемые вами сег- 
менты дойдут до перезагрузившегося хоста, в котором нет никакой информации 
о старых соединениях. В таком случае спецификация ТСР [Розе] 1981Ъ] требует, 
чтобы принимающий хост послал отправителю К$Т. В результате отправитель 
оборвет соединение, и приложение либо получит код ошибки ЕСОММВЕЗЕТ (если 
есть ожидающее чтение), либо следующая операция записи закончится сигналом 
ЗТСРТРЕ или ошибкой ЕРТРЕ. 


Резюме 


В этом разделе дано объяснение понятию «надежность ТСР». Вы узнали, что 
не существует гарантированной доставки, и при работе с ТСР могут встретиться 
разнообразные ошибки. Ни одна из этих ошибок не фатальна, но вы должны быть 
готовы к их обработке. 


Совет 10. Помните, что ТСР 
не выполняет опрос соединения 


Программисты, приступающие к изучению семейства протоколов ТСР/ТР, но 
имеющие опыт работы с другими сетевыми технологиями, часто удивляются, что 
ТСР не посылает приложению немедленного уведомления о потере связи. Поэто- 
му некоторые даже считают, что ТСР не пригоден в качестве универсальной тех- 
нологии обмена данными между приложениями. В этом разделе разъясняются 
причины отсутствия у ТСР средств для уведомления, достоинства и недостатки 
такого подхода и способы обнаружения потери связи прикладным программистом. 

Как вы узнали в совете 9, сетевой сбой или крах системы могут прервать сооб- 
щение между хостами, но приложения на обоих концах соединения «узнают» 
об этом не сразу. Приложение-отправитель остается в неведении до тех пор, пока 
ТСР не исчерпает все попытки. Это продолжается довольно долго, в системах на 
базе В$О - примерно 9 мин. Если приложение не посылает данные, то оно может 
вообще не получить информации о потере связи. Например, приложение-сервер 
ожидает, пока клиент не обратится со следующим запросом. Но, поскольку у кли- 
ента нет связи с сервером, следующий запрос не придет. Даже когда ТСР на сторо- 
не клиента прекратит свои попытки и оборвет соединение, серверу об этом будет 
ничего не известно. 

Другие коммуникационные протоколы, например ЗМА или Х.25, извещают 
приложение о потере связи. Если имеется нечто более сложное, чем простая двух- 
точечная выделенная линия, то необходим протокол опроса, который постоянно 
проверяет наличие абонента на другом конце соединения. Это может быть сообще- 
ние типа «есть что-нибудь для отправки?» или скрыты е фреймы, посылаемые в фо- 
новом режиме для непрерывного наблюдения за состоянием виртуального канала. 
В любом случае, за эту возможность приходится расплачиваться пропускной спо- 
собностью сети. Каждое такое опрашивающее сообщение потребляет сетевые ресур- 
сы, которые могли бы использоваться для увеличения полезной нагрузки. 
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Очевидно, одна из причин, по которым ТСР не уведомляет о потере связи не- 
медленно, - это нежелание жертвовать полосой пропускания. Большинству прило- 
жений немедленное уведомление и не нужно. Приложение, которому действитель- 
но необходимо срочно узнавать о недоступности другого конца, может реализовать 
для этой цели собственный механизм. Далее будет показано, как это сделать. 

Есть и философское возражение против встраивания в ТСР/1ТР механизма не- 
медленного уведомления. Один из фундаментальных принципов, заложенных при 
проектировании ТСР/ТР, - это принцип «оконечного разума» [Затег её а|. 1984]. 
В применении к сетям упрощенно подразумевается следующее. «Интеллекту» 
нужно находиться как можно ближе к оконечным точкам соединения, а сама сеть 
должна быть относительно «неинтеллектуальной». Именно поэтому ТСР обраба- 
тывает ошибки самостоятельно, не полагаясь на сеть. Как сказано в совете 1, про- 
токол [Р (значит, и построенный на его основе ТСР) делает очень мало предполо- 
жений о свойствах физической сети. Относительно мониторинга наличия связи 
между приложениями этот принцип означает, что такой механизм должен реали- 
зовываться теми приложениями, которым это необходимо, а не предоставляться 
всем приложениям без разбора. В работе [НиКета 1995] принцип «оконечного 
разума» интересно обсуждается в применении к Иицегпе. 

Однако веская причина отсутствия у ТСР средств для немедленного уведом- 
ления о потере соединения связана с одной из главных целей его проектирования: 
способностью поддерживать связь при наличии сбоев в сети. Протокол ТСР - это 
результат исследований, проведенных при финансовой поддержке Министерства 
обороны США, с целью создания надежной технологии связи между компьютера- 
ми. Такая технология могла бы функционировать даже в условиях обрывов сетей 
из-за военных действий или природных катастроф. Часто сетевые сбои быстро 
устраняются или маршрутизаторы находят другой маршрут для соединения. До- 
пуская временную потерю связи, ТСР часто может справиться со сбоями, не ставя 
об этом в известность приложения. 

Недостаток такого подхода в том, что код, отслеживающий наличие связи, не- 
обходимо встраивать в каждое приложение (которому это нужно), а непродуман- 
ная реализация может привести к ненужному расходу ресурсов или как-то иначе 
повредить пользователям. Но и в этом случае при встраивании мониторинга в при- 
ложение можно осуществить тонкую настройку алгоритма, чтобы он удовлетво- 
рял нуждам приложения и по возможности естественно интегрировался с при- 
кладным протоколом. 


Механизм контролеров 


В действительности протокол ТСР обладает механизмом обнаружения мерт- 
вых соединений - так называемыми контролерами (Кеер-аПуе). Но, как вы вскоре 
увидите, для приложений подобный механизм часто бесполезен. Если приложе- 
ние его активирует, то ТСР посылает на другой конец специальный сегмент, ког- 
да по соединению в течение некоторого времени не передавались данные. Если 
хост на другом конце доступен и приложение там все еще работает, то ТСР отвеча- 
ет сегментом АСК. В этом случае ТСР, пославший контролера, сбрасывает время 
простоя в нуль; приложение не получает извещения о том, что имел место обмен 
информацией. 


СЕ О О О РОВ 


Если хост на другом конце работает, а приложение - нет, то ТСР посылает 
в ответ сегмент В$Т. А ТСР отправивший контролер, разрывает соединение и воз- 
вращает приложению код ЕСОММВЕЗЕТ. Обычно так бывает после перезагрузки 
удаленного хоста, поскольку, как говорилось в совете 9, если бы завершилось всего 
лишь приложение на другом конце, то ТСР послал сегмент Е1М. 

Если удаленный хост не посылает в ответ ни АСК, ни В$Т, то ТСР продолжает 
посылать контролеров, пока не получит сведений, что хост недоступен. В этот мо- 
мент он разрывает соединение и возвращает приложению код ЕТТМЕРОЧТ либо, если 
маршрутизатор прислал [СМР-сообщение о недоступности хоста или сети, соответ- 
ственно код ЕНОЗТОМВЕАСН или ЕМЕТОМВЕАСН. 

Первая проблема, с которой сталкиваются приложения, нуждающиеся в не- 
медленном уведомлении, при попытке воспользоваться механизмом контроле- 
ров, — это длительность временных интервалов. В соответствии с ВЕС 1122 
[Вгадеп 1989], если ТСР реализует механизм контролеров, то по умолчанию вре- 
мя простоя должно быть не менее двух часов. И только после этого можно посылать 
контролеров. Затем, поскольку АСК, посланный удаленным хостом, доставляется 
ненадежно, процесс отправки контролеров необходимо несколько раз повторить; 
и лишь тогда можно разрывать соединение. В системе 4.4В5 О отправляется девять 
контролеров с интервалом 75 с. 


Примечание Точные величины — деталь реализации. В ЕС 1122 не говорится 
о том, сколько и с каким интервалом нужно посылать контро- 
леры, прежде чем разорвать соединение. Утверждается лишь, 
что реализация не должна интерпретировать отсутствие от- 
вета на посылку одного контролера как индикатор прекращения 
соединения. 


Таким образом, в реализациях на основе В$О для обнаружения потери связи 
потребуется 2 ч 11 мин 15 с. Этот срок приобретает смысл, если вы понимаете, что 
назначение контролеров — освободить ресурсы, занятые уже несуществующими со- 
единениями. Такое возможно, например, если клиент соединяется с сервером, а за- 
тем хост клиента неожиданно отключается. Без механизма дежурных серверу при- 
шлось бы ждать следующего запроса от клиента вечно, поскольку он не получит Е[М. 


Примечание Эта ситуация очень распространена из-за ошибок пользователей 
персональных компьютеров, которые просто выключают компью- 
тер или модем, не завершив корректно работающие приложения. 


В некоторых реализациях разрешено изменять один или оба временных ин- 
тервала, но это всегда распространяется на систему в целом. Иными словами, из- 
менение затрагивает все ТСР-соединения, установленные данной системой. Это 
и есть основная причина, по которой механизм контролеров почти бесполезен 
в качестве средства мониторинга связи. Период, выбранный по умолчанию, слиш- 
ком велик, а если его сократить, то контролеры перестанут выполнять свою ис- 
ходную задачу — обнаруживать давно «зависшие» соединения. 


ТСР не выполняет опрос соединения 11| | 99 


В последней версии стандарта РОЗ ПХ появилась новейшая опция сокета 
ТСР_КЕЕРАЦШТУЕ, которая позволяет устанавливать временной интервал для 
отдельного соединения, но пока она не получила широкого распространения. 

Еще одна проблема, связанная с механизмом контролеров, состоит в том, что 
он не просто обнаруживает «мертвые» соединения, а еще и разрывает их незави- 
симо от того, допускает ли это приложение. 


Пульсация 


Задача проверки наличия соединения, неразрешимая с помощью механизма 
контролеров, легко решается путем реализации аналогичного механизма в самом 
приложении. Оптимальный метод зависит от приложения. Здесь вы можете пол- 
нее оценить гибкость, которая может быть достигнута при реализации на приклад- 
ном уровне. В качестве примеров рассмотрим два крайних случая: 


о клиент и сервер обмениваются сообщениями разных типов, каждое из кото- 
рых имеет заголовок, идентифицирующий тип сообщения; 
о приложение передает данные в виде потока байтов без разбиения на записи. 


Первый случай сравнительно несложен. Вводится новый тип сообщения 
М5С_НЕАВТВЕАТ. Получив такое сообщение, приложение возвращает его отправи- 
телю. Такой способ предоставляет болыпую свободу. Проверять наличие связи 
могут одна или обе стороны, причем только одна действительно посылает конт- 
рольное сообщение-пульс. 

Сначала рассмотрим заголовочный файл (листинг 2.23), который используют 
как клиент, так и сервер. 


Листинг 2.23. Заголовочный файл для реализации механизма пульсации 


реагЕреаЕ. НВ 


1 #1ЕпаеЕ __НЕАВТВЕАТ_Н__ 

2 #АеЕ1те __НЕАВТВЕАТ_Н__ 

3 #аеЁЕ1пе М$С_ТУРЕЛ 1 /* Сообщение прикладного уровня. */ 
4 #АеЕ1те М$С_ТУРЕ2 2 /* Еще одно. */ 

5 #АеЕ1пе М$С_НЕАВТВЕАТ 3 /* Сообщение-пульс. */ 

6 СуреаеЕ зЕкасЕ /* Структура сообщения. */ 

А 

8 ц_11632_Е Еуре; /* М$С_ТУРЕЗТ, ... */ 

9 спак ЯЧаба[ 2000 |; 

10 } пза_Е; 
11 #АеРлпе Т1 60 /* Время простоя перед отправкой пульса. */ 
12 #АеЕ1те Т2 10 /* Время ожидания ответа. */ 


13 #ералЕ /* _ НЕАВТВЕАТ Н__ */ 
реагЕБеаё. п 


3-5 С помощью этих констант определяются различные типы сообщений, 
которыми обмениваются клиент и сервер. Для данного примера нужно 
только сообщение М5с_НЕАВТВЕАТ. 


ЕС В ПО В В В Основы 


6-10 


11 


12 


Здесь определяется структура сообщений, которыми обмениваются 
клиент и сервер. Здесь представляет интерес только поле суре. Реаль- 
ное приложение могло бы подстроить эту структуру под свои возмож- 
ности. Подробнее это рассматривается в замечаниях к листингу 2.15 
о смысле типа и_1пЕ32_6 и об опасности предположений о способе 
упаковки структур. 

Данная константа определяет, сколько времени может простаивать со- 
единение, прежде чем приложение начнет посылать контрольные со- 
общения-пульсы. Здесь произвольно выбрано 60 с, реальное же при- 
ложение должно подобрать значение, наиболее соответствующее его 
потребностям и виду сети. 

Эта константа определяет, сколько времени клиент будет ждать ответа 
на контрольное сообщение. 


В листинге 2.24 приведен текст клиента, который инициирует посылку конт- 
рольных сообщений. Такой выбор абсолютно произволен, в качестве инициатора 
можно было выбрать сервер. 


Листинг 2.24. Клиент, посылающий контрольные сообщения-пульсы 


ВЬ_с11епЕё.с 


1 #1ос1аае "еЕЁср.В" 
2 #1пс1аае “"БеагЕеБеае.В" 
3 1п6 ма1п( 1п6 агос, сваг **агау ) 


ГЕа_зее а11Еа; 
[а_зеф геааЕа; 
п59_6 м5а; 

$Екгисе Елтеуа1 6%; 


ЗОСКЕТ 3; 

116 гс; 

106 РеагеБеае$ = 0; 

106 сп = в12еоЁ( пза ); 
ТМТТ(); 


$ = Еср_с11епе( агду[ 1 ], ахау[ 2 ] ); 
ЕО_РЕВО( &а11Еа ); 
ЕО ЗЕТ( $, ба11Еа }; 
Су. су _зес = 11; 
Су. цзес = 0; 
с В 
{ 
геа ЕЯ = а11Еа; 
гс = се1есь( $ + 1, &геааЕа, мо, МЬЬ, &№у ); 
УЕ ва 20:2 
еггог( 1, еггпо, "ошибка вызова зе]1есё" ); 
1ЁЕ ( гс == 0 ) /* Произошел тайм-аут. */ 
{ 
1Е ( ++пеагеБеаез > 3 } 
еггог( 1, 0, "соединения нет\п" ); 
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29 еггог( 0, 0, "посылаю пульс #%А\п", ВеагеБеаез )}; 

30 мза.Ссуре = №оп1( М5С_НЕАВТВЕАТ ); 

31 ГС = зепа( з, ( сЪаг * }&тз9, э172еоЁ( пза ), 0); 

32 2Е (тс < 0) 

33 еггог( 1, еггпо, "ошибка вызова зепа" ); 

34 Су. су_зес = Т2; 

35 сопЕ1пие; 

36 } 

37 1Е ( |!ЕР_15$ЕТ( з, &геааЕа ) ) 

38 еггог( 1, 0, "зе1есЕ вернул некорректный сокет\п" }; 

39 гс = гесу( зв, ( саг * }&мза + э12еоЁ( пизда ) - спе, 

40 СПЕ: :0 

41 1Е (тс == 0) 

42 еггог ( 1, 0, "сервер закончил работу\п" ); 

43 и 

44 еггог( 1, еггпо, "ошибка вызова гесу" ); 

45 ПеагЕЪеаез = 0; 

46 Су.ЕУ_вес = Т1; 

47 спё -= гс; /* Встроенный геа@п. */ 

48 1Е ( спе > 0) 

49 сопё1пще; 

50 спЕ = $12еоЁ( шва ); 

51 /* Обработка сообщения. */ 

52 } 

53 } 

ВЬ_с]1епё.с 

Инициализация 

13-14 Выполняем стандартную инициализацию и соединяемся с сервером, 
адрес и номер порта которого заданы в командной строке. 

15-16 Задаем маску для системного вызова зе1еск, в которой выбран ваш 
сокет. 

17-18 Взводим таймер на Т1 секунд. Если за это время не было получено ни- 
какого сообщения, то зе1ес® вернет управление с индикацией сраба- 
тывания таймера. 

21-22 Устанавливаем маску, выбирающую сокет, из которого читаем, после 
чего система блокирует программу в вызове зе1еск, пока не поступят 
данные либо не сработает таймер. 

Обработка тайм-аута 

27-28 Если послано подряд более трех контрольных пульсов и не получено 
ответа, то считается, что соединение «мертво». В этом примере просто 
завершаем работу, но реальное приложение могло бы предпринять бо- 
лее осмысленные действия. 

29-33 Если максимальное число последовательных контрольных пульсов не 
достигнуто, посылается новый пульс. 

34-35 Устанавливаем таймер на Т2 секунд. Если за это время не получен от- 


вет, то либо отправляется новый пульс, либо соединение признается 
«мертвым» в зависимости от значения переменной НеагеЪеа(з. 
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Обработка сообщения 
37-38 Если зе1ес® вернул сокет, отличный от соединенного с сервером, то 


39-40 


41-44 
45-46 


47-50 


завершаемся с сообщением о фатальной ошибке, 

Вызываем гесу для чтения одного сообщения. Эти строки, а также сле- 
дующий за ними код, изменяющий значение переменной спЕ, -— не что 
иное, как встроенная версия функции геадп. Она не может быть вы- 
звана напрямую, поскольку заблокировала бы весь процесс на неопре- 
деленное время, нарушив тем самым работу механизма пульсации. 
Если получаем признак конца файла или ошибку чтения, выводим ди- 
агностическое сообщение и завершаем сеанс. 

Поскольку только что получен ответ от сервера, сбрасывается счетчик 
пульсов в 0 и переустанавливается таймер на Т1 секунд. 

Эти строки завершают встроенный вариант геайап. Уменьшаем пере- 
менную спе на число, равное количеству только что прочитанных байт. 
Если прочитано не все, то следует повторить цикл с вызова зе1есе. 
В противном случае заносится в спё полная длина сообщения и завер- 
шается обработка только что принятого сообщения. 


Листинг 2.25 содержит текст сервера для этого примера. Здесь предполагается 
что сервер также будет следить за состоянием соединения, но это не обязательно. 


Листинг 2.25. Сервер, отвечающий на контрольные сообщения-пульсы 


очмироь ь- 


ВЬ_5зегуег.с 


#1п0с1аЧе "еёср.В" 
#1пс1аае "ВеахеБеае.В" 


зп ма1п( 106 агас, спаг **агау ) 


{ 


ГА_зеЕ а11Еа; 

[а_зее геааЕа; 

п5а_Е м5а; 

зЕгисЕ Е1теуа1 %У; 

ЗОСКЕТ $; 

ЗОСКЕТ $1; 

пе гс; 

106 п1ззе4_Пеагереаез = 0; 
1106 спЕ = в12еоЁ( шза ); 


ТМТТ о); 
$ = Сср_вегуег( МОЬЬ, агау[ 1] ); 
51 = ассере( $, №, № ); 
3Е ( 1!15уа11@азосКк( $1 )} ) 
еггог( 1, егхпо, "ошибка вызова ассерё" }; 
Су. Су_5ес = Т1 + 12; 
Су.Еу авес = 0; 
РО_СЕВО( &а11Еа ); 
РО_ЗЕТ( $1, &а11ёа )}; 
оС”) 


{ 
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25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
ей 
52 
53 
54 
Б5 
56 


57 
58 
59 


60 
61 
62 
63 
64 


65 
66 
67 
68 
69 
70 
ит 


} 


геааЕа = а11Еа; 


гс 
Е 


1Е 
{ 


( 


зе1есе( $1 + 1, &хеааЕа, МмМО.Ь, мМлл,, &Е\у 
гс <0) 


ехгог( 1, еггпо, "ошибка вызова 5е1есе" ); 


( 


ТЕ 


гс == 0 ) /* Произошел тайм-аут. */ 


( ++1135еа_реагЕЬеаез > 3 ) 
еггох( 1, 0, "соединение умерло\п" ); 


еггог( 0, 0, "пропущен пульс #%А\п", 


11з5еа_Пеагереаез )}; 


Су. СУ_вес = Т2; 
сопЕ1пие; 


р 


1Е ( 'РО_Т$5ЕТ( $81, &гкеааёа )} ) 
еггог( 1, 0, "зе1есЕ вернул некорректный сокет\п" ); 
гс = гесу( $1, ( сраг * )&мза + з17еоЁ( пза ) - спе, 
спе, 0}; 
1Е (тс ==0 } 
еггог( 1, 0, "клиент завершил работу\п" }; 
ТЕ 0.) 
еггог( 1, еггпо, "ошибка вызова гесу" }; 
п1з5еа_НеакгЕреаез = 0; 
фу. Еу_вес = Т1 + Т2; 
спЕ -= гс; /* Встроенный геаап. */ 
1Е ( сп > 0) 
сопЕ1пае; 
спе 512е0оЁ( пза ); 
зи1ЕсП ( пбор1( пшза.буре ) ) 
{ 
сазе М$С_ТУРЕ1 
/* Обработать сообщение типа ТУРЕ1. */ 
Ъгеак; 
сазе М$С_ТУРЕ2 
/* Обработать сообщение типа ТУРЕ. */ 
Ьгеак; 
сазе М$5С_НЕАБТВЕАТ : 
ГС = зеп@( °1, ( сраг * )&мза, в17е0Ё( пза ), 0); 
1Е (тс < 0) 
еггог( 1, еггпо, "ошибка вызова зеп@" }; 
ЬгеаКк; 
ДеЕац1 6 
еггог( 1, 0, "неизвестный тип сообщения (%а)\п", 


} 


пеор1 ( пза.буре } ); 


в: 0 


} 


ЬЬ_зегуег.с 
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Инициализация 


14-18 


19-20 


21-22 


25-28 


Выполняем стандартную инициализацию и принимаем соединение от 
клиента. 

Взводим таймер на Т1 + Т2 секунд. Поскольку клиент посылает пульс 
после Т1 секунд неактивности, следует подождать немного больше — 
на Т2 секунд. 

Инициализируем маску для зе1еск, указывая в ней соединенный со- 
кет, из которого происходит чтение. 

Вызываем зе1ес® и проверяем возвращенное значение. 


Обработка тайм-аута 


31-32 


35 


Если пропущено более трех пульсов подряд, то соединение считается 
«мертвым» — работа завершается. Как и клиент, реальный сервер мог 
бы предпринять в этом случае более осмысленные действия. 

Взводим таймер на Т2 секунд. К этому моменту клиент должен был 
бы посылать пульсы каждые Т2 секунд, так что если за это время ни- 
чего не получено, то необходимо увеличить счетчик пропущенных 
пульсов. 


Обработка сообщения 


38-39 
40-41 
42-45 


46-47 


48-51 
60-64 


Производим ту же проверку корректности сокета, что и в клиенте. 
Как и в клиенте, встраиваем код функции геадп. 

Если гесу возвращает признак конца файла или код ошибки, то печа- 
таем диагностическое сообщение и выходим. 

Поскольку только что получено сообщение от клиента, соединение все 
еще живо, так что сбрасываем счетчик пропущенных пульсов в нуль 
и взводим таймер на Т1 + Т2 секунд. 

Этот код, такой же, как в клиенте, завершает встроенную версию геа@п. 
Если это сообщение-пульс, то возвращаем его клиенту. Когда кли- 
ент получит сообщение, обе стороны будут знать, что соединение 
еще есть. 


Для тестирования этих программ запустим программу ВЪ_зегуег на машине 
зрагс, а программу ПЬ_с11епё -— на машине Ъза. После того как клиент соеди- 
нится с сервером, отключим зрагс от сети. Вот что при этом будет напечатано: 


5рагс: $ ВЬ_ вехуех 9000 Ьза: $ ВЬ с11ере врагс 9000 
ЮЬ_зегуег: пропущен пульс #1 ВЬ_с11еп$: посылаю пульс #1 
ПЬ_зекуехк: пропущен пульс #2 ВЬ_с11епе: посылаю пульс #2 
ПЬ_зекуег: пропущен пульс #3 ПБ_с11епе: посылаю пульс #3 
ПЬ_зегуег: соединения нет ПБ с11епё: соединения нет 
зрагс: $ Ьза: $ 


Еще один пример пульсации 


Использованная в предыдущем примере модель не совсем пригодна в ситуации, 
когда одна сторона посылает другой поток данных, не разбитый на сообщения. 
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Проблема в том, что посланный пульс оказывается частью потока, поэтому его 
придется явно выискивать и, возможно, даже экранировать (совет 6). Чтобы из- 
бежать сложностей, следует воспользоваться другим подходом. 

Идея в том, чтобы использовать для контрольных пульсов отдельное соедине- 
ние. На первый взгляд, кажется странной возможность контролировать одно со- 
единение с помощью другого. Но помните, что делается попытка обнаружить крах 
хоста на другом конце или разрыв в сети. Если это случится, то пострадают оба 
соединения. Задачу можно решить несколькими способами. Традиционный спо- 
соб — создать отдельный поток выполнения ({геа4) для управления пульсацией. 
Можно также применить универсальный механизм отсчета времени, который раз- 
работан в совете 20. Однако, чтобы не вдаваться в различия между АР] потоков на 
платформе \УМп32 и библиотекой РТЬгеа4$ в ОМХ, модифицируем написанный 
для предыдущего примера код с использованием системного вызова зе1есе. 

Новые версии клиента и сервера очень похожи на исходные. Основное разли- 
чие состоит в логике работы зе1есе, который теперь должен следить за двумя со- 
кетами, а также в дополнительном коде для инициализации еще одного соединения. 
После соединения клиента с сервером, клиент посылаетему номер порта, по которо- 
му отслеживается пульсация сервера. Это напоминает то, что делает ЕТР-сервер, 
устанавливая соединение для обмена данными с клиентом. 


Примечание Может возникнуть проблема, если для преобразования частных 
сетевых адресов в открытые используется механизм МАТ (со- 
вет 3). В отличие от ситуации с ЕТР программное обеспечение 
МАТ не имеет информации, что нужно подменить указанный 
номер порта преобразованным. В таком случае самый простой 
путь — выделить приложению второй хорошо известный порт. 


Начнем с логики инициализации и установления соединения на стороне кли- 
ента (листинг 2.26). 


Листинг 2.26. Код инициализации и установления соединения на стороне клиента 


рЬ_с11епё2.с 
#1пс1аАае "ебср.В" 
#1пс1аае "БеахгеБеа®.П" 


106 ма1п( 1106 агкгас, свВаг **агау ) 
{ 

Еа_зее а11Еа; 

а_вее геааЁа; 

сраг пза[ 1024 }; 

$Егасе Е1теуа1 &му; 

5ЕгасЕ зоскааахг_1п №Б1156еп; 

СОСКЕТ заака; 

СОСКЕТ зПЪ; 

СОСКЕТ $11$56еп; 

11Е тс; 

106 6511з6еп]еп = з12еоЁ( РБ] 156еп ); 


нь на на у 
ьшьнохоючмиьвь юн 
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15 106 БеагЕБеаез = 0; 
16 1п1Е пахЕа1; 
17 спаг Помза[ 1 ]; 


18 ТМ1Т(); 

19 511еСеп = сср_зекуег( МОШ, "0" )}; 

20 кс = десзосКпаме( $э11з6еп, ( эзекиасЕ зосКааахг * )&НЬ11з6ер, 
21 &2611збеп1еп ); 

ВЕ бе) 

23 еггог( 1, егхгро, "ошибка вызова дебзоскКпаше" ); 

24 заага = Еср_с11епе ( акау[ 1 |], акаду[ 2 ] ); 

25 кс = зеп@( зЧаба, ( сраг * )&251186еп.з1п_рогё, 

26 312еоЁ( 251136 еп.51п_рогё ), 0}; 

27 1Е (тс < 0) 

28 еггог( 1, ехгпо, "ошибка при посылке номера порта" }; 
29 зНЬ = ассере( $11в6еп, МЬЬ, М ); 

30 1Е ( 1!15%а11Аазоск( эЪЬ } } 

31 еггог( 1, ехггпо, "ошибка вызова ассерё”" }; 


32 РО _ВЕВО( &а11Еа ); 

33 ЕШБ_5ЕТ( зааба, &а11Еа ); 

34 РО СЕТ( зВЬ, &а11Еа ); 

35 пахЕ@1 = { зааба > эБЬ ? зааба: эВ } + 1; 


36 &х 
37 у 


„.Ем_зес = 711; 
„Су цзес = 0; 
ВЬ_с11епвёЁ2.с 


Инициализация и соединение 


19-23 


24-28 


29-31 


32-37 


Вызываем функцию Еср_зегуег с номером порта 0, таким образом за- 
ставляя ядро выделить эфемерный порт (совет 18). Затем вызываем 
деЕзосКпаме, чтобы узнать номер этого порта. Это делается потому, что 
с данным сервером ассоциирован только один хорошо известный порт. 
Соединяемся с сервером и посылаем ему номер порта, с которым он 
должен установить соединение для посылки сообщений-пульсов. 
Вызов ассер® блокирует программу до тех пор, пока сервер не устано- 
вит соединение для пульсации. В промышленной программе, наверное, 
стоило бы для этого вызова взвести таймер, чтобы программа не «за- 
висла», если сервер не установит соединения. Можно также проверить, 
что соединение для пульсации определил именно тот сервер, который 
запрашивался в строке 24. 

Инициализируем маски для зе1есё и взводим таймер. 


Оставшийся код клиента показан в листинге 2.27. Здесь вы видите обработку 
содержательных сообщений и контрольных пульсов. 


Листинг 2.27. Обработка сообщений клиентом 


38 Рок 
39 { 
40 


ВЬ_с11епЕЁ?2.с 
Е) 


геааЕЯ = а11а; 
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41 ГС = се1есе( махЁая1, &геааЕа, моьЬ, М, &ву ); 
42 1Е (гс < 0) 


43 егуоу( 1, егупо, "ошибка вызова зе1есе" ); 

44 1ЁЕ ( гс == 0 }) /* Произошел тайм-аут. */ 

45 { 

46 1Е ( ++РеагЕБеаев > 3 } 

47 еггог( 1, 0, "соединения нет\п" ); 

48 еггог( 0, 0, "посылаю пульс #%А\п", феагёБеаейз ); 
49 ус = зепа( зэВЬ, "", 1,0); 

50 1Е (тс < 0) 

51 еггог( 1, еггпо, "ошибка вызова зепа" }; 

52 Бу.бу_вес = Т2; 

53 сопё1пае; 

54 } 

55 1Е ( ЕО Т5ЗЕТ( эВЬ, &геааЕа } ) 

56 { 

57 гс = гесу( эВЬ, ЮБмва, 1, 0); 

58 1Е (тс == 0) 

59 еггохг( 1, 0, "сервер закончил работу ($5ВЬ)\п" ); 
60 1Е (тс < 0) 

61 егкгохг( 1, еггпо, "ошибка вызова гесу для сокета зПЪ" 
; 

62 . 

63 1Е ( РО_Т5У5ЗЕТ( эЧаба, &геааЕа ) ) 

64 { 

65 гс = гесу( зааба, мза, $12еоЁ( шза }), 0); 

66 ЛЕ (ус == 0) 

677 еггог( 1, 0, "сервер закончил работу (зЯЧаба)\п" ); 
68 1Е (тс < 0) 

69 егтог( 1, еггпо, "ошибка вызова гесу" }; 

70 /* Обработка данных. */ 

71 } 

72 РеагёБеаез = 0; 

73 бу. Еу_зес = 11; 

74 } 

75 } 


РЬ_ с11ерЕЁё.с 


Обработка данных и пульсов 


40-43 Вызываем функцию зе1еск и проверяем код возврата. 

44-54 Таймаут обрабатывается так же, как в листинге 2.24, только пульсы 
посылаются через сокет ВБ. 

25-62 Если через сокет зНЪ пришли данные, читаем их, но ничего не делаем. 

63-71 Если данные пришли через сокет эздака, читаем столько, сколько смо- 
жем, и обрабатываем. Обратите внимание, что теперь производится 
работа не с сообщениями фиксированной длины. Поэтому читается не 
больше, чем помещается в буфер. Если данных меньше длины буфера, 
вызов гес\ вернет все, что есть, но не заблокирует программу. Если 
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данных больше, то из сокета еще можно читать. Поэтому следующий 
вызов зе1ес* немедленно вернет управление, и можно будет обрабо- 
тать очередную порцию данных. 

72-73 Поскольку только что пришло сообщение от сервера, сбрасываем пере- 
менную НеагЕЪеаез в 0 и снова взводим таймер. 


И взаключение рассмотрим код сервера для этого примера (листинг 2.28). Как 
и код клиента, он почти совпадает с исходным сервером (листинг 2.25) за тем ис- 
ключением, что устанавливает два соединения и работает с двумя сокетами. 


Листинг 2.28. Код инициализации и установления соединения на стороне сервера 


рЬ_зегуег2.с 


1 #1пс]аае "ебср.п" 
2 #110с1аае "реагеЪБеае.В" 
3 106 ма1п( 116 агас, саг **агау } 
4 { 
5 Еа_зеЕ а11Еа; 
6 ЕЯ_зеё геа@Еа; 
7 сваг пза[ 1024 ]; 
8 зЕгисЕ зоскаааг_1п реег; 
9 зЕкисЕ Е1меуа]1 &\у; 
10 ЗОСКЕТ 3; 
11 ЗОСКЕТ зааба; 
12 ЗОСКЕТ з1Ъ; 
13 тие тс: 
14 106 пахЁа1; 
15 106 п155еа_Пеахгереаез$ = 0; 
16 106 реег1еп = $12еоЁ( реег )}; 
17 спаг ПЬмза[ 1 ]; 
18 мт (0); 
19 $ = Еср_зегуег( МОШ,, агау[ 1 }] ); 
20 зааба = ассерЕ( 5, ( зЕхисЕ зоскаааг * )}&реек, 
21 &реег1еп }; 
22 1Е ( 1!15уа11азосКк( заава } ) 
23 еггог( 1, еггпо, "ассерЕ Ёа11е@а" }; 
24 гс = геаап( заса, ( сраг * )&реег.з1п_роге, 
25 $12е0Ё( реег.з1п_рохгё } }; 
26 Ета < 0 
27 еггог( 1, еггпо, "ошибка при чтении номера порта" ); 
28 5 = зоскее( РЕ_ТМЕТ, $О0СК_$5ТВЕАМ, 0 )}; 
29 1Е ( 1!13уа11азосКк( эВЪ ) } 
30 еггог( 1, еггпо, "ошибка при создании сокета вНЪ" )}; 
31 гс = соппесе( зРЬ, ( зегасЕ зоскаааг * )бреег, реег]еп }; 
32 Еве.) 
33 еггог( 1, еггпо, "ошибка вызова соппесЕ для сокета 81" ); 
34 Су.су_вес = Т1 + Т2; 
35 Су.6у_ извес = 0; 
36 ЕР _СЕВО( &а11Еа ); 
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37 ЕО _ЗЕТ( зЯаба, &а11Еа ); 
38 ГО ЗЕТ( эНЬ, &а11Еа ); 
39 пахЁЯ1 = ( зЯаба > зН!Ь ? зЯаба : зПЬ ) +1; 
рЬ_5егуег2.с 


Инициализация и соединение 


19-23 Слушаем и принимаем соединения от клиента. Кроме того, сохраняем 
адрес клиента в переменной реег, чтобы знать, с кем устанавливать со- 
единение для пульсации. 

24-27 Читаем номер порта, который клиент прослушивает в ожидании соеди- 
нения для пульсации. Считываем его непосредственно в структуру реег. 
О преобразовании порядка байтов с помощью НЕопз или пеоНз беспо- 
коиться не надо, так как порт уже пришел в сетевом порядке. В таком 
виде его и надо сохранить в реек. 

28-33 Получив сокет эВ Ъ, устанавливаем соединение для пульсации. 

34-39 Взводим таймер и инициализируем маски для зе1есё. 


Оставшаяся часть сервера представлена в листинге 2.29. 


Листинг 2.29. Обработка сообщений сервером 


рЬ_зегуег2.с 
ЗО ОЕ: аа’ 
41 { 
42 геааЁЯ = а11ЕЯ; 
43 гс = зе1есе( пахЁЯ1, &геааЕа, МОШЫ, МОБЦ, &%у ); 
44 1Е (тс < 0) 


45 еггог( 1, еггпо, "ошибка вызова зе1есё" }; 

46 1Е ( гс == 0 ) /* Произошел тайм-аут. */ 

47 { 

48 3Е ( ++т1зеа_ БеагЕЪБеаез > 3 ) 

49 еггог( 1, 0, "соединения нет\п" }; 

50 еггог( 0, 0, "пропущен пульс #%А\п", 

51 п1з5еа_реагЕЪБеаез$ ); 

52 су.су_зес = Т2; 

53 сопё1пе; 

54 } 

55 3Е ( РО _Т5УЗЕТ( з№Ь, &геааЁа ) ) 

56 { 

57 гс = гесу( зЪЬ, ББтза, 1, 0); 

58 ЗЕ (тс == 0) 

29 еггог( 1, 0, "клиент завершил работу\п" }; 
60 ТЕ те: 

61 еггог( 1, еггпо, "ошибка вызова гесу для сокета зП0Ь" )}; 
62 ус = зепЯ( зЪЪ, НЫпза, 1, 0); 

63 1Е (гс <0) 

64 еггог( 1, еггпо, "ошибка вызова зепЯ для сокета эПЬ" ); 
65 } 


66 1Е ( ЕО_Т55ЗЕТ( зааса, &хеааЕа ) ) 
67 { 
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68 гс = гесу( зааба, шза, 312еоЁ( пза ), 0); 
69 1Е (тс == 0} 

70 еггог( 1, 0, "клиент заверщил работу\п" }; 
71 1Е (тс < 0} 

72 еггог( 1, еггпо, "ошибка вызова гесу" ); 
73 /* Обработка данных. */ 

74 } 

75 п15зе_РеагЕЪеаез = 0; 

76 Су.ву_зес = Т1 + Т2; 

77 } 

78 ЕХТТ( О); 

79 } 


ЬЬ_зехуег2.с 

42-45 Как и в ситуации с клиентом, вызываем зе1ес® и проверяем возвра- 
щаемое значение. 

46-53 Обработка тайм-аута такая же, как и в первом примере сервера в лис- 
тинге 2.25. 

55-65 Если в сокете зНЬ есть данные для чтения, то читаем однобайтовый 
пульс и возвращаем его клиенту. 

66-74 Если что-то поступило по соединению для передачи данных, читаем 
и обрабатываем данные, проверяя ошибки и признак конца файла. 

72-76 Поскольку только что получены данные от клиента, соединение все 
еще живо, поэтому сбрасываем в нуль счетчик пропущенных пульсов 
и Переустанавливаем таймер. 


Если запустить клиента и сервер и имитировать сбой в сети, отсоединив один 
из хостов, То получим те же результаты, что при запуске п_зегуег и НЬ_с11епё. 


Резюме 


Хотя ТСР и не предоставляет средств для немедленного уведомления клиента 
о потере связи, тем не менее несложно самостоятельно встроить такой механизм 
в приложение. Здесь рассмотрены две модели реализации контрольных сообще- 
ний-пульсов. На первый взгляд, это может показаться избыточным, но одна мо- 
дель не подходит для всех случаев. 

Первый способ применяется, когда приложения обмениваются между собой 
сообщениями, содержащими поле идентификатора типа. В этом случае все очень 
просто: достаточно добавить еще один тип для сообщений-пульсов. «Родители» 
могут спокойно работать — их «дети» под надежным присмотром. 

Второй способ применим в ситуации, когда приложения обмениваются пото- 
ком байтов без явно выраженных границ сообщений. В качестве примера можно 
назвать передачу последовательности нажатий клавиш. В данном примере исполь- 
зовано отдельное соединение для приема и передачи пульсов. Разумеется, тот же 
метод можно было бы применить и в первом случае, но он несколько сложнее, чем 
простое добавление нового типа сообщения. 

В книге «ОМГХ Мебхогк Ргоргаттитя» [З{еуепз 1998] описан еще один метод 
организации пульсации с помощью механизма срочных данных, имеющегося 
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в ГСР. Это лишний раз демонстрирует, какие разнообразные возможности име- 
ются в распоряжении прикладного программиста для организации уведомления 
приложения о потере связи. 

Наконец, следует напомнить, что хотя было сказано только о протоколе ТСР, 
то же самое верно и в отношении ОПОР. Представим сервер, который посылает 
широковещательные сообщения нескольким клиентам в локальной сети или орга- 
низует групповое вещание на глобальную сеть. Поскольку соединения нет, клиенты 
не имеют информации о крахе сервера, хоста или сбое в сети. Если в датаграммах 
есть поле типа, то серверу нужно лишь определить тип для датаграммы-пульса 
и посылать ее, когда в сети какое-то время не было других сообщений. Вместо этого 
он мог бы рассылать широковещательные датаграммы на отдельный порт, который 
клиенты прослушивают. 


Совет 11. Будьте готовы к некорректному 
поведению партнера 


Часто при написании сетевых приложений не учитывают возможность возник- 
новения ошибки, считая ее маловероятной. В связи с этим ниже приведена выдерж- 
ка из требований к хостам, содержащихся в КЕС 1122 [Вгадеп 1989, стр. 12]: «Про- 
грамма должна обрабатывать любую возможную ошибку, как бы маловероятна она 
ни была; рано или поздно придет пакет именно с такой комбинацией ошибок иат- 
рибутов, и если программа не готова к этому, то неминуем хаос. Правильнее всего 
предположить, что сеть насыщена злонамеренными агентами, которые посылают 
пакеты, специально подобранные так, чтобы вызвать максимально разрушитель- 
ный эффект. Необходимо думать о том, как защититься, хотя надо признать, что 
наиболее серьезные проблемы в сети Гиегпе были вызваны непредвиденными ме- 
ханизмами, сработавшими в результате сочетания крайне маловероятных событий. 
Никакой злоумышленник не додумался бы до такого!» 

Сегодня этот совет более актуален, чем во время написания. Появилось мно- 
жество реализаций ТСР и некоторые из них содержат грубые ошибки. К тому 
же все больше программистов разрабатывают сетевые приложения, но далеко 
не у всех есть опыт работы в этой области. 

Однако самый серьезный фактор — это лавинообразный рост числа подклю- 
ченных к И\цегпеё персональных компьютеров. Ранее можно было предполагать, 
что у пользователей есть хотя бы минимальная техническая подготовка, они пони- 
мали, к каким последствиям приведет, скажем, выключение компьютера без пред- 
варительного завершения сетевого приложения. Теперь это не так. 

Поэтому особенно важно практиковать защитное программирование и пред- 
видеть все действия, которые может предпринять хост на другом конце, какими 
бы маловероятными они ни казались. Эта тема уже затрагивалась в совете 9 при 
обсуждении потенциальных ошибок при работе с ТСР, а также в совете 10, где 
речь шла об обнаружении потери связи. В этом разделе будет рассмотрено, какие 
действия вашего партнера могут нанести ущерб. Главное - не думайте, что он бу- 
дет следовать прикладному протоколу, даже если обе стороны протокола реализо- 
вывали вы сами. 
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Проверка завершения работы клиента 


Предположим, что клиент извещает о желании завершить работу, посылая 
серверу запрос из одной строки, в которой есть только слово аи1*. Допустим да- 
лее, что сервер читает строки из входного потока с помощью функции геа411пе 
(ее текст приведен в листинге 2.32), которая была описана в совете 9. Что про- 
изойдет, если клиент завершится (аварийно или нормально) раньше, чем пошлет 
команду ча1Е? ТСР на стороне клиента отправит сегмент ЕТМ\, после чего опера- 
ция чтения на сервере вернет признак конца файла. Конечно, это просто обнару- 
жить, только сервер должен обязательно это сделать. Легко представить себе та- 
кой код, предполагая правильное поведение клиента: 


оо ВЮ 
{ 
1Е ( хгеа911пе( в, РаЕ, в12еоЁ( БЕ ) ) <0) 
еггог( 1, егхпо, "ошибка вызова геаЯ11пе" ); 
1Е ( зегспр( БаЁ, "ач1е\0" ) == 0) 
/* Выполнить функцию завершения клиента. */ 
е1зе 
/* Обработать запрос. */ 


} 


Хотя код выглядит правильным, он не работает, поскольку будет повторно об- 
рабатывать последний запрос, если клиент завершился, не послав команду 41. 

Предположим, что вы увидели ошибку в предыдущем фрагменте (или нашли 
ее после долгих часов отладки) и изменили код так, чтобы явно обнаруживался 
признак конца файла: 


ТЕ 
{ 
гс = геаа11те( $, РаЁ, э1хеоЁ( БаЕЁ } }; 
ЕЕ. во 
егхгог( 1, екггпо, "ошибка вызова геа@Я11пе" ); 
1Е (кс == 0 || зегсир( БаЕЁ, "ац1\п" ) == 0) 
/* Выполнить функцию завершения клиента. */ 
е] зе 
/* Обработать запрос. */ 


} 


И этот код тоже неправилен, так как в нем не учитывается случай, когда хост 
клиента «падает» до того, как клиент послал команду ачи1* или завершил работу. 
В этом месте легко принять неверное решение, даже осознавая проблему. Для про- 
верки краха клиентского хоста надо ассоциировать таймер с вызовом геа@11пе. 
Потребуется примерно в два раза больше кода, если нужно организовать обработ- 
ку «безвременной кончины» клиента. Представив себе, сколько придется писать, 
вы решаете, что шансов «грохнуться» хосту клиента мало. 

Но проблема в том, что хосту клиента и необязательно завершаться. Если это 
ПК, то пользователю достаточно выключить его, не выйдя из программы. А это 
очень легко, поскольку клиент мог исполняться в свернутом окне или в окне, 
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закрытом другими, так что пользователь про него, вероятно, забыл. Есть и другие 
возможности. Если соединение между хостами установлено с помощью модема 
на клиентском конце (так сегодня выполняется большинство подключений к - 
{егпе(), то пользователь может просто выключить модем. Шум в линии также мо- 
жет привести к обрыву соединения. И все это с точки зрения сервера неотличимо 
от краха хоста клиента. 


Дримечание При некоторых обстоятельствах ошибку, связанную с модемом, 
можно исправить, повторно набрав номер (помните, что ТСР 
способен восстанавливаться после временных сбоев в сети), но 
зачастую 1[Р-адреса обоих оконечных абонентов назначаются 
динамически сервис-провайдером при установлении соединения. 
В таком случае маловероятно, что будет задан тот же адрес, 
и поэтому клиент не сможет оживить соединение. 


Для обнаружения потери связи с клиентом необязательно реализовывать 
пульсацию, как это делалось в совете 10. Нужно всего лишь установить тайм-аут 
для операции чтения. Тогда, если от клиента в течение определенного времени не 
поступает запросов, то сервер может предположить, что клиента больше нет, и ра- 
зорвать соединение. Так поступают многие ЕТР-серверы. Это легко сделать, либо 
явно установив таймер, либо воспользовавшись возможностями системного вызо- 
ва зе1ес®, как было сделано при реализации пульсации. 

Если вы хотите, чтобы сервер не «зависал» навечно, то можете воспользовать- 
ся механизмом контролеров для разрыва соединения по истечении контрольного 
тайм-аута. В листинге 2.30 приведен простой ТСР-сервер, который принимает со- 
общение от клиента, читает из сокета и пишет результат на стандартный вывод. 
Чтобы сервер не «завис», следует задать для сокета опцию $0_КЕЕРАЬТУЕ с помо- 
щью вызова зе зоскоре. Четвертый аргумент зеёзосКкоре должен указывать на 
ненулевое целое число, если надо активировать посылку контролеров, или на ну- 
левое целое, чтобы ее отменить. 

Запустите этот сервер на машине Ъза, а на другой машине -— программу {епеё 
в качестве клиента. Соединитесь с сервером, отправьте ему строку «пе11о», чтобы 
соединение точно установилось, а затем отключите клиентскую систему от сети. 
Сервер напечатает следующее: 


Ьза: $ Кеер 9000 
Бе11о 
Клиент отключился от сети. 
Спустя 2 ч 11 мин 15 с. 
Кеер: ошибка вызова гесу: Орега®1оп Е еЯ оц (60) 
Ьеа: $ 


Как и следовало ожидать, ТСР на машине Ъза разорвал соединение и вернул 
серверу код ошибки ЕТТМЕРООПТ. В этот момент сервер завершает работу и осво- 
бождает все ресурсы. 
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Листинг 2.30. Сервер, использующий механизм контролеров 


Кеер.с 
1 #10с1аае "еёср.р" 
2 1пЕ та1п( 106 агас, срах **акау ) 
З. 4 
4 ЗОСКЕТ 3; 
5 СОСКЕТ $1; 
6 156 оп = 1; 
7 тие гс; 
8 српаг раЕЁ[ 128 |]; 
9 ТМтТ(); 
10 3 = Сср зегуек( МТЪЬ, агау[ 1 ] }; 
11 $1 = ассерЕ( $, МЫ, № ); 
12 1Е ( 1!153уа11АзосКк( 81 ) } 
13 ехгок( 1, екггпо, "ошибка вызова ассере\п" ); 
14 1Е ( зеёзосКоре( $з1, $О0._ЗОСКЕТ, $О0_КЕЕРАГТУЕ, 
15 ( сраг * )&оп, з12еоЁ( оп ) } ) 
16 еггохг( 1, екгпо, "ошибка вызова зебзоскоре" ); 
1 ОЕ. (182) 
18 { 
19 ГС = геа9110е( з1, РоаЁ, з12еоЁ( ЪаЕЁ ) ); 
20 УЕ. ва ==. 0 
21 еггог( 1, 0, "другой конец отключился\п" }; 
22 Еще 0) 
23 еггог( 1, еггпо, "ошибка вызова гесу" }; 
24 мгабе( 1, ВЕ, гс ); 
25 } 
26 } 
Кеер.с 


Проверка корректности входной информации 


Чго бы вы ни программировали, не думайте, что приложение будет получать 
только те данные, на которые рассчитывает. Пренебрежение этим принципом - 
при чер отсутсгвия защитного программирования. Хочется надеяться, что профес- 
сиональный нрограммист, разрабатывающий коммерческую программу, всегда ему 
следует. Однако часто это правило игнорируют. В работе [МШег её а|. 1995] опи- 
сывается, как авторы генерировали случайный набор входных данных и подавали 
его па вход всевозможных стандартных утилит УМХ от разных производителей. 
При этом им удалось «сломать» (с дампом памяти) или «подвесить» (в бесконеч- 
ном цикле) от 6 до 43% тестируемых программ (в зависимости от производителя). 
В семи исследованных коммерческих системах частота отказов составила 23%. 

Вывод ясен: если такие результаты получены при тестировании зрелых про- 
грамм, когорые принято считать программами «промышленного качества», то тем 
более необходимо защищаться и подвергать сомнению все места в программе, где 
неожиданные входные данные могут привести к нежелательным результатам. Рас- 
смотрим несколько примеров, когда неожиданные данные оказываются источни- 
ком ошибок. 
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Две самые распространенные причины краха приложений - это переполнение 
буфера и сбитые указатели. В вышеупомянутом исследовании именно эти две 
ошибки послужили причиной большинства сбоев. Можно сказать, что в сетевых 
программах переполнение буфера должно быть редким явлением, так как при об- 
ращении к системным вызовам, выполняющим чтение (геаа, гесу, гесуЁкгом, 
геаду и геадтза), всегда необходимо указывать размер буфера. Но вы увидите 
далее, как легко допустить такую ошибку. (Это рассмотрено в замечании к строке 42 
программы зпаЕаомт .с в совете 16.) 

Чтобы понять, как это происходит, разработаем функцию геаа1 1пе, исполь- 
зовавшуюся в совете 9. Поставленная задача — написать функцию, которая счи- 
тывает из сокета в буфер одну строку, заканчивающуюся символом новой строки, 
и дописывает в конец двоичный нуль. На начало буфера указывает параметр Ъч. 


О неее Пен ит ИЯ О СН о В ЗИЕ БОБ СВ БЫ Л 


#1пс1а9е "еёср.\" 
116 геа911пе( ЗОСКЕТ 5, сраг *РиЕЁ, $12е_+ ]1ел ); 


Возвращаемое значение: число прочитанных байтов или -1 в случае ошибки. 
Первая попытка реализации, которую надо отбросить сразу, похожа на следу- 
ЮЩИЙ Код: 


\011е ( гесу( Еа, ‚, &5°, 1,0) == 1) 
{ 
ВЕБЕ =: 6: 
ТЕ ( с == "\п" } 
ргеак; 


} 


/* Проверка ошибок, добавление завершающего нуля и т.д. */ 
Прежде всего, многократные вызовы гесу совсем неэффективны, поскольку 
при каждом вызове нужно два переключения — в режим ядра и обратно. 


Прамечание Но иногда приходится писать и такой код — смотрите, напри- 
мер, функцию геааск1ЕЁ в листинге 3.10. 


Важнее, однако, то, что нет контроля переполнения буфера. 
Чтобы понять, как аналогичная ошибка может вкрасться и в более рациональ- 
ную реализацию, следует рассмотреть такой фрагмент: 


зсае1с срагк *Ър; 
збае1с 106 спе = 0; 
$Сае1с срагк Ъ|[ 1500 |; 


сБаг с; 
ОЕ Ре.) 
{ 
ЛЕ (спе-- <= 0) 
{ 
спЕ = гесу( Еа, Ь, э1леоЕЁ() Ь), 0); 


1Е ( СПЕ < 0) 
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гесагп -1: 


1Е ( спё == 0) 
гебцгп 0; 
Бр = Ь; 


- = *Ър++; 
*ЬаЕрег++ = с; 
ЕС == АВ") 
{ 
*риЕрЕк = "\0"; 
Ьгеак; 


} 


В этой реализации нет неэффективности первого решения. Теперь считывает- 
ся большой блок данных в промежуточный буфер, а затем по одному копируются 
байты в окончательный буфер; по ходу производится поиск символа новой стро- 
ки. Но при этом в коде присутствует та же ошибка, что и раньше. Не проверяется 
переполнение буфера, на который указывает переменная Ба Ёрег. Можно было бы 
и не писать универсальную функцию чтения строки; такой код — вместе с ошиб- 
кой — легко мог бы быть частью какой-то большей функции. 

А теперь напишем настоящую реализацию (листинг 2.31). 


Листинг 2.31. Неправильная реализация геаа те 


геаа11пе.с 
1 1пЕ геаа110е( $ОСКЕТ Еа, срак *БаЁрЕехг, з12е_Е 1еп ) 
а. ‘4 
3 спаг *раЁх = БаЁрег; 
4 зеае1с срагк *Ър; 
5 збаезс 106 спб = 0; 
6 з6а®1с спахг Ъ[ 1500 |; 
7 
8 


сваг с; 

\611е ( 1еп -->0) 
9 { 
10 1Е ( спЕ -- <=0 ) 
11 { 
12 спЕ = гесу( Еа, Ъ, з12еоЕ( ББ), 0); 
13 1Е ( сё < 0} 
14 гебиги -1; 
15 1Е ( спё == 0) 
16 гекигп 0; 
17 Юр = в; 
18 } 
19 с = *Бр++; 
20 *БиЕрет++ = с; 
21. Е Ге == "Аа" ) 
22 { 


23 *БЫЕрЕЕ- = "0" 
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24 гегагп БаЁрег - БаЁх; 
25 } 

26 } 

27 вес_егхгпо( ЕМЗССТИЕ )}; 

28 гебогп -1; 

29 } 


геаЯ]11пе.с 


На первый взгляд, все хорошо. Размер буфера передается геаа1 1пе и во внеш- 
нем цикле проверяется, не превышен ли он. Если размер превышен, то перемен- 
ной еггпо присваивается значение ЕМ5СУТОЕ и возвращается -1. 

Чтобы понять, в чем ошибка, представьте, что функция вызывается так: 


ГС = геаа11пе( в, БаЕЁЕек, 10 }; 
и при этом из сокета читается строка 
123456789<п1> 


Когда в с записывается символ новой строки, значение 1еп равно нулю. Это 
означает, что данный байт последний из тех, что готовы принять. В строке 20 поме- 
щаете символ новой строки в буфер и продвигаете указатель БаЁрёг за конец буфе- 
ра. Ошибка возникает в строке 23, где записывается нулевой байт за границу буфера. 

Заметим, что похожая ошибка имеет место и во внутреннем цикле. Чтобы уви- 
деть ее, представьте, что при входе в функцию геаа11пе значение спё равно нулю 
и гесу возвращает один байт. Что происходит дальше? Можно назвать это «опус- 
тошением» (ипдегНо\) буфера. 

Этот пример показывает, как легко допустить ошибки, связанные с переполне- 
нием буфера, даже предполагая, что все контролируется. В листинге 2.32 приведе- 
на окончательная, правильная версия геаа11пе. 


Листинг 2.32. Окончательная версия геа те 


геаЯ11пе.с 
106 геаа11пе( СОСКЕТ Ея, свахк *БаЁЕрег, в17е_е 1еп ) 
{ 
спаг *раЁх = раЕрёг; 
зЕае1с сПпаг *Ър; 
8баб1с 116 спе = 0; 
збае1с спах Ъ[ 1500 }; 


сраг с; 
%111е ( --1еп > 0) 
{ 
1Е ( --спЕ <= 0) 
{ 
спе = гесу( Еа, Ъ, в12еоЕ(Ъ), 0}; 
1ЁЕ ( спе <0) 


{ 
1Е ( еггро == ЕТМТВ ) 
{ 


нана ны на а а 
эф ноюхо змпмилььоьюн- 
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17 1еп++; /* Уменьшим на 1 в заголовке мп11е. */ 
18 сопЕ1пице; 

19 } 

20 гебигп -1; 

21 } 

22 ТЕ ( сп == 0) 

23 тегико 0; 

24 Бр = В; 

25 } 

26 с = *Бр++; 

27 *риЕрег++ = с; 

28 ТЕ ЕСД 2) 

29 { 

30 *БиЕрек = "\0"; 

31 гебцгп раЕрехг - БаЁх; 
32 } 

33 } 

34 сес_еггпо( ЕМЗУСЗТАЕ ); 
35 тебиги -1; 

36 } 


геаЯ11пе.с 


Единственная разница между этой и предыдущей версиями в том, что умень- 
шаются значения 1еп и спё до проверки, а не после. Также проверяется, не верну- 
ла ли гесу значение ЕТМТК. Если это так, то вызов следует повторить. При умень- 
шении 1 еп до использования появляется гарантия, что для нулевого байта всегда 
останется место. А, уменьшая спе, можно получить некоторую уверенность, что 
данные не будут читаться из пустого буфера. 


Резюме 


Вы всегда должны быть готовы к неожиданным действиям со стороны пользо- 
вателей и хостов на другом конце соединения. В этом разделе рассмотрено два 
примера некорректного поведения другой стороны. Во-первых, нельзя надеяться 
на то, что партнер обязательно сообщит вам о прекращении передачи данных. Во- 
вторых, продемонстрирована важность проверки правильности входных данных 
и разработана функция геаа] 1пе, устойчивая к ошибкам. 


Совет 12. Не думайте, что программа, работающая 
в локальной сети, будет работать и в глобальной 


Многие сетевые приложения разрабатываются и тестируются в локальной 
сети или даже на одной машине. Это просто, удобно и недорого, но при этом могут 
остаться незамеченными некоторые ошибки. 

Несмотря на возможную потерю данных, показанную в совете 7, локальная 
сеть представляет собой среду, в которой датаграммы почти никогда не теряются, 
не задерживаются и практически всегда доставляются в правильном порядке. Од- 
нако из этого не следует делать вывод, что приложение, замечательно работающее 
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ПНА В И ПОВ ЕТ: 


в локальной сети, будет также хорошо функционировать и в глобальной сети или 
в Ицегпеё. Здесь можно столкнуться с проблемами двух типов: 


о производительность глобальной сети оказывается недостаточной из-за до- 
полнительных сетевых задержек; 
о некорректный код, работавший в локальной сети, отказывает в глобальной. 


Если вам встречается проблема первого типа, то, скорее всего, приложение 
следует перепроектировать. 


Недостаточная производительность 


Чтобы получить представление о такого рода проблемах, изменим программы 
|р_зегуег (листинг 2.25) и НЬ_с11еп (листинг 2.24), задав Т1, равным 2 с, аТ2 — 
1 с (листинг 2.23). Тогда пульс будет посылаться каждые две секунды, и при отсут- 
ствии ответа в течение трех секунд приложение завершится. 

Сначала запустим эти программы в локальной сети. Проработав почти семь 
часов, сервер сообщил о пропуске одного пульса 36 раз, а о пропуске двух пуль- 
сов — один раз. Клиенту пришлось посылать второй пульс 11 из 12139 раз. И кли- 
ент, и сервер работали, пока клиент не остановили вручную. Такие результаты 
типичны для локальной сети. Если не считать редких и небольших задержек, со- 
общения доставляются своевременно. 

А теперь запустим те же программы в [тегпе*. Спустя всего лишь 12 мин кли- 
ент сообщает, что послал три пульса, не получив ответа, и завершает сеанс. Распе- 
чатка выходной информации от клиента, частично представленная ниже, показы- 
вает, как развивались события: 


зрагс: $ ЪЬ с11епре 205.184.151.171 9000 

ВБ с11епе: посылаю пульс: #1 

ПБ _с11епе: посылаю пульс: #2 

ПЬ_с11епе: посылаю пульс: #3 

ПБ _с11епе: посылаю пульс: #1 

ПЬ_ с11епе: посылаю пульс: #2 

ВБ _с11епе: посылаю пульс: #1 
Много строк опущено. 

РЬ_с11епе: посылаю пульс: #1 

ВЬ_с11епе: посылаю пульс: #2 

ПБ_с11епе: посылаю пульс: #1 

ВЬ_с11епё: посылаю пульс: #2 

ВЬ_с11ерё: посылаю пульс: #3 

ЮЬ_с11епе: посылаю пульс: #1 

ВЬ_с11епё: посылаю пульс: #2 

ВБ сепё: Соединение завершается через 
1 с после последнего пульса. 

зрагс: $ 


В этот раз клиент послал первый пульс 251 раз, а второй - 247 раз. Таким об- 
разом, он почти ни разу не получил вовремя ответ на первый пульс. Десять раз 
клиенту пришлось посылать третий пульс. 
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Сервер также продемонстрировал значительное падение производительнос- 
ти. Тайм-аут при ожидании первого пульса происходил 247 раз, при ожидании 
второго пульса - 5 и при ожидании третьего пульса - 1 раз. 

Этот пример показывает, что приложение, которое прекрасно работает в усло- 
виях локальной сети, может заметно снизить производительность в глобальной. 


Скрытая ошибка 


В качестве примера проблемы второго типа рассмотрим основанное на ТСР 
приложение, занимающееся телеметрией. Здесь сервер каждую секунду принима- 
ет от удаленного датчика пакет с результатами измерений. Пакет может состоять 
из двух или трех целочисленных значений. В примитивной реализации подобного 
сервера мог бы присутствовать такой цикл: 


те окЕГ 
то фе) 
{ 
гс = гесу( з, ( свВаг * ) рКЕ, в1хеоЁ( ркё ), 0); 
1Е (кс 1!= в12еоЁ( 116 ) * 2 && гс != э12еоЁЕ( 116 ) * 3 } 
/* Протоколировать ошибку и выйти. */ 
е1зе 


/* Обработать гс / э12еоЁ( 116 ) значений. */ 


} 


Из совета 6 вы знаете, что этот код некорректен, но попробуем провести про- 
стое моделирование. Напишем сервер (листинг 2.33), в котором реализован толь- 
ко что показанный цикл. 


Листинг 2.33. Моделирование сервера телеметрии 


Ум (е1ещеёту5.с 
#1пс1аае "ееср.П" 


1 

2 #аАеЕ1пе ТИОТМТ$ ( з17еоЁ( 116 ) * 2) 

3 #аеЕ1пе ТНВЕЕТМТ$ ( эз12еоЁ( 116 ) * 3) 

4 106 па1п( 116 агдс, спаг **агду ) 

Э = 

6 ЗОСКЕТ 8; 

7 ЗОСКЕТ $1; 

8 тие те; 

9 11061 = 1; 
10 тре КЕ 3]: 

11 ТМТТ(); 

12 $5 = Еср_зегуег( МОШЬ, агду[ 1 ] ); 

13 $1 = ассере( в, МЫ, М ); 

14 1Е ( 1!15уа11ЯзосКкК( $1 ) ) 

15 еггог( 1, еггпо, "ошибка вызова ассерё" ); 
16 О) 

17 { 

18 гс = гесу{( 31, ( стахк * )рКЕ, з12еоЕ( ркё }, 0); 
19 1Е ( гс != ТМОТМТ$ && гс != ТНВЕЕТМТ$ ) 
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20 еггог( 1, 0, "гесу вернула %Я\п", гс }; 

21 рг1пЕЁЕ( "Пакет %А содержит %А значений в %А байтах\п", 
22 1++, пбор1( РКО] ), гс ); 

23 } 

24 } 


се1емебхуз.с 


11-15 В этих строках реализована стандартная инициализация и прием со- 
единения. 

16-23 В данном цикле принимаются данные от клиента. Если получено при чте- 
НИИ НЕ В ТОЧНОСТИ $12еоЁ( 106 ) *2 ИЛИ з12еоЁ( 10% ) * 3 байт, то 
протоколируем ошибку и выходим. В противном случае байты первого 
числа преобразуются в машинный порядок (совет 28), а затем резуль- 
тат и число прочитанных байтов печатаются на зЕ доче. В листинге 2.34 
вы увидите, что клиент помещает число значений в первое число, по- 
сылаемое в пакете. Это поможет разобраться в том, что происходит. 
Здесь не используется это число как «заголовок сообщения», содержа- 
щий его размер (совет 6). 


Для тестирования этого сервера также необходим клиент, который каждую 
секунду посылает пакет целых чисел, имитируя работу удаленного датчика. Текст 
клиента приведен в листинге 2.34. 


Листинг 2.34. Имитация клиента для сервера телеметрии 


Ее]етеёгус.с 
1 #1пс1аАе "ебср.В" 

2 116 па1п( 116 агас, спаг **агау ) 

а 

4 ЗОСКЕТ 3; 

5 116 тс; 

6 106 1; 

7 2 Е В 
8 


тмттТ(); 

9 з = Еср_с11еп6( агау[ 1 ], агау[ 2 ] ); 

10 Рог (1=2;;1=5-1)}} 
11 { 

12 РКЕГ 0 ] = № отт (1); 
13 гс = зепа( 3, ( спаг * )рКкё, 1 * з152еоЁ( 106 ), 0); 
14 ТЕ (0) 

15 еггог( 1, еггпо, "ошибка вызова зепа" ); 
16 31еер( 1 ); 

17 } 

18 } 


ЕБе1етеёгус.с 


8-9 Производим инициализацию и соединяемся с сервером. 

10-17 Каждую секунду посылаем пакет из двух или трех целых чисел. Как 
говорилось выше, первое число в пакете - это количество последую- 
щих чисел (преобразованное в сетевой порядок байтов). 


Основы 
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Для тестирования модели запустим сервер на машине Ъ39, а клиента — на ма- 
шине зрагс. Сервер печатает следующее: 


Ъз@а: $ Ее1емеегув 9000 
Пакет 1 содержит 2 значения в 8 байтах 
Пакет 2 содержит 3 значения в 12 байтах 
Много строк опущено. 
Пакет 22104 содержит 3 значения в 12 байтах 
Пакет 22105 содержит 2 значения в 8 байтах 
Клиент завершил сеанс через 
6 ч 8 мин 15 с. 
Се1емебсгуз: гесу вернула 0 
Ъза: $ 


Хотя в коде сервера есть очевидная ошгибка, он проработал в локальной сети 
без сбоев более шести часов, после чего моделирование завершили с помощью руч- 
ной остановки клиента. 


Примечание Протокол сервера проверен с помощью сценария, написанного на 
ашё — необходимо убедиться, что каждая операция чтения вер- 
нула правильное число байтов. 


Однако при запуске того же сервера через егпей результаты получились сов- 
сем другие. Опять запустим клиента на машине зрагс, а сервер — на машине за, 
НО на этот раз заставим клиента передавать данные через глобальную сеть, указав 
ему адрес сетевого интерфейса, подключенного к Пицегпее. Как видно из последних 
строк, напечатанных сервером, фатальная ошибка произошла уже через 15 мин. 


Пакет 893 содержит 2 значения в 8 байтах 

Пакет 894 содержит 3 значения в 12 байтах 

Пакет 895 содержит 2 значения в 12 байтах 

Пакет 896 содержит -268436204 значения в 8 байтах 
Пакет 897 содержит 2 значения в 12 байтах 

Пакет 898 содержит -268436204 значения в 8 байтах 
Пакет 899 содержит 2 значения в 12 байтах 

Пакет 900 содержит -268436204 значения в 12 байтах 
Се1емебсгуз: гесу вернула 4 

за: $ 


Ошибка произошла при обработке пакета 895, когда нужно было прочесть 
8 байт, а прочли 12. На рис. 2.21 представлено, что произошло. 

Числа слева показывают, сколько байтов было в приемном буфере ТСР на сто- 
роне сервера. Числа справа — сколько байтов сервер реально прочитал. Вы види- 
те, что пакеты 893 и 894 доставлены и обработаны, как и ожидалось. Но, когда 
се1етесхуз вызвал гесу для чтения пакета 895, в буфере было 20 байт. 


Примечание Трассировка сетевого трафика, полученная с помощью програм- 
мы Есраопр (совет 34), показывает, что в этот момент были 
потеряны ТСР-сегменты, которыми обменивались два хоста. 


Работа в локальной и глобальной сетях 
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Вероятно, причиной послужила временная перегрузка сети, из- 
за которой промежуточный маршрутизатор отбросил пакет. 
Перед доставкой пакета 895 клиент Ее]етеЕгус уже подгото- 
вил пакет 896, и оба были доставлены вместе. 


В пакете 895 было 8 байт, но, поскольку уже пришел пакет 896, сервер прочи- 
тал пакет 895 и первое число из пакета 896. Поэтому в распечатке видно, что было 
прочитано 12 байт, хотя пакет 895 содержит только два целых. При следующем 
чтении возвращено два целых из пакета 896, и се1емеегуз напечатал мусор вмсс- 
то числа значений, так как Ее1етеёгус не инициализировал второе значение. 


Готово 8 байт | Прочитано 8 байт 


Готово 12 байт Прочитано 12 байт 


Прочитано 12 байт 
Готово 20 байт 


Прочитано 8 байт 
Прочитано 12 байт 
Готово 20 байт 


Прочитано 8 байт 


Ринат. знании». У небось, 


Прочитано 12 байт 


Готово 28 байт 
Прочитано 12 байт 


} Прочитано 4 байта 


Рис. 2.21. Фатальная ошибка 


Как видно из рис. 2.21, то же самое произошло с пакетами 897 и 898, так что 
при следующем чтении было доступно уже 28 байт. Теперь с е1етеегуз читает 
пакет 899 и первое значение из пакета 900, остаток пакета 900 и первое значение 
из пакета 901 и наконец последнее значение из пакета 901. Последняя операция 
чтения возвращает только 4 байта, поэтому проверка в строке 19 завершается ис- 
удачно, а моделирование - с ошибкой. 

К сожалению, на более раннем этапе моделирования произошло еще худшее. 


Пакет 31 содержит 2 значения в 8 байтах 

Пакет 32 содержит 3 значения в 12 байтах 

Пакет 33 содержит 2 значения в 12 байтах 

Пакет 34 содержит -268436204 значения в 8 байтах 
Пакет 35 содержит 2 значения в 8 байтах 

Пакет 36 содержит 3 значения в 12 байтах 
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Всего через 33 с после начала моделирования произошла ошибка, оставшаяся 
необнаруженной. Как показано на рис. 2.22, когда Ее1етеехуз читал пакет 33, 
в буфере было 20 байт, поэтому операция чтения вернула 12 байт вместо 8. Это 
означает, что пакет с двумя значениями ошибочно был принят за пакет с тремя зна- 
чениями, а затем наоборот. Начиная с пакета 35, Ее1ещеегуз восстановил синхро- 
низацию, и ошибка прошла незамеченной. 


Готово 8 байт } Прочитано 8 байт 


Готово 12 байт Прочитано 12 байт 


Прочитано 12 байт 
Готово 20 байт 


Прочитано 8 байт 


Готово 8 байт Прочитано 8 байт 


Готово 12 байт Прочитано 12 байт 


"ОН, ЧН ИЕР НИНУ ЧИН) 


Рис. 2.22. Незамеченная ошибка 


Резюме 


Локальная сеть, которая представляет собой почти идеальную среду, может мас- 
кировать проблемы производительности и даже ошибки. Не думайте, что приложе- 
ние, работающее в локальной сети, будет также хорошо работать и в глобальной. 

Из-за сетевых задержек приложение, производительность которого в локаль- 
ной сети была удовлетворительной, в глобальной сети может работать неприем- 
лемо медленно. В результате иногда приходится перепроектировать программу. 

Из-за перегрузок в интенсивно используемой глобальной сети, особенно в т- 
{егпек, данные могут доставляться как внезапно, так и пакетами неожиданного раз- 
мера. Это требует от вас особой осторожности в допущениях о том, сколько дан- 
ных может прийти в определенный момент и с какой частотой они поступают. 

Хотя в этом разделе говорилось исключительно о протоколе ТСР, то же отно- 
сится и к ОШОР поскольку он не обладает встроенной надежностью, чтобы проти- 
востоять тяжелым условиям в Пцегпей. 


Совет 13. Изучайте работу протоколов 


В книге [5еуепз 1998] автор отмечает, что основные проблемы в сетевом про- 
граммировании не имеют отношения ни к программированию, ни к АР!. Они воз- 
никают из-за непонимания работы сетевых протоколов. Это подтверждают вопро- 
сы, которые задают в конференциях, посвященных сетям (совет 44). Например, 
некто, читая справочную документацию на своей ОМХ- или Уп4о\з-машине, 
обнаруживает, как отключить алгоритм Нейгла. Но если он не понимает принципов 
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управления потоком, заложенных в ТСР и роли этого алгоритма, то вряд ли раз- 
берется, когда имеет смысл его отключать, а когда - нет, 

Точно так же, отсутствие механизма немедленного уведомления о потере свя- 
зи, обсуждавшееся в совете 10, может показаться серьезным недостатком, если вы 
не понимаете, почему было принято такое решение. Разобравшись с причинами, 
можно без труда организовать обмен сообщениями-пульсами именно с той часто- 
той, которая нужна конкретному приложению. 

Есть несколько способов изучить протоколы, и многие из них будут рассмотрены 
в главе 4. Основной источник информации о протоколах ТСР/Р - это ВЕС, кото- 
рый официально определяет, как они должны работать. В КЕС обсуждается ши- 
рокий спектр вопросов разной степени важности, в том числе все протоколы из се- 
мейства ТСР/Р. Все КЕС, а также сводный указатель находятся на следующем сайте: 
Вер: /АммлмгЕ-еАог.огв. 

В совете 43 описаны также другие способы получения ВЕС. 

Поскольку ВЕС - это плод труда многих авторов, они сильно различаются 
доступностью изложения. Кроме того, некоторые вопросы освещаются в несколь- 
ких ВЕС и не всегда просто составить целостную картину. 

Существуют и другие источники информации о протоколах, более понятные для 
начинающих. Два из них будут рассмотрены здесь, а остальные - в главе 4. 

В книге [Сотег 1995] описываются основные протоколы ТСР/ТР и то, как они 
должны работать, с точки зрения ВЕС. Здесь содержатся многочисленные ссылки 
на ВЕС, которые облегчают дальнейшее изучение предмета и дают общее представ- 
ление об организации ВЕС. Поэтому некоторые считают эту книгу теоретическим 
введением в противоположность книгам [З%4еуепз 1994; Зцеуепз 1995], где представ- 
лен подход, ориентированный в основном на практическое применение. 

В книгах Стивенса семейство протоколов ТСР/ТР исследуется с точки зрения 
реализации. Иными словами, показывается, как основные реализации ТСР/ТР ра- 
ботают в действительности. В качестве инструмента исследования используются, 
главным образом, данные, выдаваемые программой Есраипр (совет 34), и времен- 
ные диаграммы типа изображенной на рис. 2.16. В сочетании с детальным изложе- 
нием форматов пакетов и небольшими тестовыми программами, призванными про- 
яснить некоторые аспекты работы обсуждаемых протоколов, это дает возможность 
ясно представить себе их функционирование. С помощью формального описания 
добиться этого было бы трудно. 

Хотя в этих книгах приняты разные подходы к освещению протоколов ТСР/ 
ТР, не следует думать, будто один подход чем-то лучше другого, а стало быть, от- 
давать предпочтение только одной книге. Полезность каждой книги зависит от 
поставленной перед вами задачи в данный момент. По сути, издания взаимно до- 
полняют друг друга. И серьезный программист, занимающийся разработкой сете- 
вых приложений, должен включить эти две книги в свою библиотеку. 


Резюме 


В этом разделе обсуждалось, насколько важно разбираться в функционирова- 
нии протоколов. Отмечено, что официальной спецификацией ТСР/ПР являются 
ВЕС и рекомендованы книги Комера и Стивенса в качестве дополнительного ис- 
точника информации о протоколах и их работе. 
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Совет 14. Не воспринимайте слишком серьезно 
семиуровневую эталонную модель 051 


Поскольку задача проектирования и реализации сетевых протоколов очень слож- 
на, обычно ее разделяют на меньшие части, более простые для понимания. Традици- 
онно для этого используется концепция уровней. Каждый уровень предоставляет 
сервисы уровням выше себя и пользуется сервисами нижележащих уровней. 

Например, на рис. 2.1, где изображен упрощенный стек протоколов ТСРЛР уро- 
вень [Р предоставляет сервис, именуемый доставкой датаграмм, уровням ТСР и ППР. 
Чтобы обеспечить такой сервис, [Р пользуется сервисами для передачи датаграмм фи- 
зическому носителю, которые предоставляет уровень сетевого интерфейса. 


Модель О5$1 


Наверное, самый известный пример многоуровневой схемы сетевых протоко- 
лов — это эталонная модель открытого взаимодействия систем (КеЁегепсе Мо4е! 
оЁ Ореп Зу$етз ПиегсоппесИоп), предложенная Международной организацией по 
стандартизации (130). 


Примечание Многие ошибочно полагают, что в модели О51 были впервые вве- 
дены концепции разбиения на уровни, виртуализации и многие 
другие. На самом деле, эти идеи были хорошо известны и актив- 
но применялись разработчиками сети АКРАМЕТ, которые со- 
здали семейство протоколов ТСР/ТР задолго до появления моде- 
ли О5Т. Об истории этого вопроса вы можете узнать в КЕС 871 
[Раайр5Ку 1982]. 


Поскольку в этой модели семь уровней (рис. 2.23), 
ее часто называют семиуровневой моделью ОЗ1. 

Как уже отмечалось, уровень М предоставляет сер- 
висы уровню №+1 и пользуется сервисами, предостав- 
ляемыми уровнем М-1. Кроме того, каждый уровень 
может взаимодействовать только со своими непосред- 
ственными соседями сверху и снизу. Это взаимо- 
действие происходит посредством четко определенных 
интерфейсов между соседними уровнями, поэтому 
в принципе реализацию любого уровня можно заме- 
нить при условии, что новая реализация предостав- 
ляет в точности те же сервисы, и это не отразится 
на остальных уровнях. Одноименные уровни в комму- 
никационных стеках обмениваются данными (по сети) с помощью протоколов. 

Эти уровни часто упоминаются в литературе по вычислительным сетям. Каж- 
дый из них предоставляет следующие сервисы: 


Прикладной уровень 
Уровень представления 
Сеансовый уровень 
Транспортный уровень 


Сетевой уровень 


юоъамоч+ 


Канальный уровень 


Физический уровень 


Рис. 2.23. Семиуровневая 
талонная модель О$! 


о физический уровень. Этот уровень связан с аппаратурой. Здесь определяются 
электрические и временные характеристики интерфейса, способ передачи би- 
тов физическому носителю, кадрирование и даже размеры и форма разъемов; 


Семиуровневая модель 051 В 
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О канальный уровень. Это программный интерфейс к физическому уровню. 
В его задачу входит предоставление надежной связи с последним. На этом 
уровне находятся драйверы устройств, используемые сетевым уровнем для 
общения с физическими устройствами. Кроме того, этот уровень обеспечи- 
вает формирование кадров для канала, проверку контрольных сумм с целью 
обнаружения искажения данных и управление совместным доступом к фи- 
зическому носителю. Обычно задача интерфейса между сетевым и каналь- 
ным уровнями — создание механизма, обеспечивающего независимость от 
конкретного устройства; 

О сетевой уровень. Этот уровень занимается доставкой пакетов от одного узла 
другому. Он отвечает за адресацию и маршрутизацию, фрагментацию и сбор- 
ку, а также за управление потоком и предотвращение перегрузок; 

о транспортный уровень. Реализует надежную сквозную связь между узлами 
сети, а также управление потоком и предотвращение перегрузок. Он компен- 
сирует ненадежность, присущую нижним уровням, за счет обработки оши- 
бок, которые вызваны искажением данных, потерей пакетов и их доставкой 
не по порядку; 

О сеансовый уровень. Транспортный уровень предоставляет надежный полно- 
дуплексный коммуникационный канал между двумя узлами. Сеансовый 
уровень добавляет такие сервисы, как организация и уничтожение сеанса 
(например, вход в систему и выход из нее), управление диалогом (эмуляция 
полудуплексного терминала), синхронизация (создание контрольных точек 
при передаче больших файлов) и иные надстройки над надежным протоко- 
лом четвертого уровня; 

о ировень представления. Отвечает за представление данных, например, пре- 
образование форматов (скажем, из кода АЗСИ в код ЕВСОГС) и сжатие; 

О прикладной уровень. На нем располагаются пользовательские программы, 
использующиеся остальными четырьмя уровнями для обмена данными. Из- 
вестные из мира ТСР/ТР примеры - это {епек, Ёр, почтовые клиенты и \/еБ- 
браузеры. 


Официальное описание семиуровневой модели ОЗ приведено в документе 
[[уеграбопа! З{ап4аг4$ ОтватигаНоп 1984], но оно лишь в общих чертах деклариру- 
ет, что должен делать каждый уровень. Детальное описание сервисов, предоставля- 
емых протоколами на отдельных уровнях, содержится в других документах 150. 
Довольно подробное объяснение модели и ее различных уровней со ссылками на 
соответствующие документы [$0 можно найти в работе []аш ап4 Азгама]а 1993]. 

Хотя модель ОЗ] полезна как основа для обсуждения сетевых архитектур 
и реализаций, ее нельзя рассматривать как готовый чертеж для создания любой 
сетевой архитектуры. Не следует также думать, что размещение некоторой функ- 
ции на уровне М в этой модели означает, что только здесь наилучшее для нее место. 

Модель ОЗ] имеет множество недостатков. Хотя, в конечном итоге, были со- 
зданы работающие реализации, протоколы ОЗ] на сегодняшний день утратили ак- 
туальность. Основные проблемы этой модели в том, что, во-первых, распределение 
функций между уровнями произвольно и не всегда очевидно, во-вторых, она была 
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спроектирована (комитетом) без готовой реализации. Вспомните, как разрабаты- 
вался ТСР/И1Р, стандарты которого основаны на результатах экспериментов. 

Другая проблема модели О$] - это сложность и неэффективность. Некоторые 
функции выполняются сразу на нескольких уровнях. Так, обнаружение и исправ- 
ление ошибок происходит на большинстве уровней. 

Как отмечено в книге [Тапепаит 1996], один из основных дефектов модели 
ОГ состоит в том, что она страдает «коммуникационной ментальностью». Это 
относится и к терминологии, отличающейся от общеупотребительной, и к специ- 
фикации примитивов интерфейсов между уровнями, которые более пригодны для 
телефонных, а не вычислительных сетей. 

Наконец, выбор именно семи уровней продиктован, скорее, политическими, 
а не техническими причинами. В действительности сеансовый уровень и уровень 
представления редко встречаются в реально работающих сетях. 


Модель ТСР/1Р 


Сравним модель ОЗГ с моделью ТСР/[Р. Важно отдавать себе отчет в том, что 
модель ТСР/ТР документирует дизайн семейства протоколов ТСР/ТР. Ее не пред- 
полагалось представлять в качестве эталона, как модель ОЗГ. Поэтому никто и не 
рассматривает ее как основу для проектирования новых сетевых архитектур. Тем 
не менее поучительно сравнить две модели и посмотреть, как уровни ТСР/ТР ото- 
бражаются на уровни модели ОЗ1. По крайней мере, это напоминает, что модель- 
ОЗТ - не единственный правильный путь. 


Прикладной уровень 
Уровень представления Прикладной уровень {ете\{, Нр, ит.д. 
Сеансовый уровень 
Транспортный уровень Транспортный уровень | ТСР, ЦОР 
Сетевой уровень Межсетевой уровень |Р, СМР, ЮМР 


Канальный уровень 
Интерфейсный уровень 


Физический уровень 


Модель ОЗ Стек ТСРЛР 


Рис. 2.24. Сравнение модели О$! и стека ТСРИР 


Как видно из рис. 2.24, стек протоколов ТСР/[Р состоит из четырех уровней. 
На прикладном уровне решаются все задачи, свойственные прикладному уровню, 
уровню представления и сеансовому уровню модели ОЗ1. Транспортный уровень 
аналогичен соответствующему уровню в ОЗГ и занимается сквозной доставкой. 
На транспортном уровне определены протоколы ТСР и ОШР на межсетевом - 
протоколы ТР, [СМР и {СМР (Пкегпеё Стоир Мапаретепе Ргобосо]). Он соответ- 
ствует сетевому уровню модели ОЗ]. 
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Драмечание С протоколом 1Р вы уже знакомы. [СМР (ищете Сопио] Меззаве 
Ртотосо!) — это межсетевой протокол контрольных сообщений, 
который используется для передачи управляющих сообщений 
и информации об ошибках между системами. Например, сооб- 
щение «хост недоступен» передается по протоколу 1СМР, рав- 
но как запросы и ответы, формируемые утилитой р1пд. [СМР 
(тете! Стоир МапаветепЕ Руоюсо!) — это межсетевой прото- 
кол управления группами, с помощью которого хосты сообща- 
ют маршрутизаторам, поддерживающим групповое вещание, 
о принадлежности к локальным группам. Хотя сообщения 
протоколов [СМР и [СМР передаются в виде [Р-датаграмм, они 
рассматриваются как неотземлемая часть [Р, а не как прото- 
колы более высокого уровня. 


Интерфейсный уровень отвечает за взаимодействие между компьютером и фи- 
зическим сетевым оборудованием. Он приблизительно соответствует канальному 
и физическому уровням модели ОЗТ. Интерфейсный уровень по-настоящему не 
описан в документации по архитектуре ТСР/Р. Там сказано только, что он обес- 
печивает доступ к сетевой аппаратуре системно-зависимым способом. 

Прежде чем закончить тему уровней в стеке ТСР/ТР, рассмотрим, как проис- 
ходит общение между уровнями стека протоколов в компьютерах на разных кон- 
цах сквозного соединения. На рис. 2.25 изображены два стека ТСР/ТР на компью- 
терах, между которыми расположено несколько маршрутизаторов. 

Вы знаете, что приложение передает данные стеку протоколов. Потом они 
опускаются вниз по стеку, передаются по сети, затем поднимаются вверх по стеку 
протоколов компьютера на другом конце и наконец попадают в приложение. Но 
при этом каждый уровень стека работает так, будто на другом конце находится 
только этот уровень и ничего больше. Например, если в качестве приложения вы- 
ступает ЕТР то ЕТР-клиент «говорит» непосредственно с ЕТР-сервером, не имея 
сведений о том, что между ними есть ТСР, [Р и физическая сеть. 

Это верно и для других уровней. Например, если на транспортном уровне ис- 
пользуется протокол ТСР, то он общается только с протоколом ТСР на другом 
конце, не зная, какие еще протоколы и сети используются для поддержания «бесе- 
ды». В идеале должно быть так: если уровень М посылает сообщение, то уровень М 
на другом конце принимает только его, а все манипуляции, произведенные над 
этим сообщением нижележащими уровнями, оказываются невидимыми. 

Последнее замечание требует объяснения. На рис. 2.25 вы увидите, что транс- 
портный уровень - самый нижний из сквозных уровней, то есть таких, связь меж- 
ду которыми устанавливается без посредников. Напротив, в «разговоре» на межсе- 
тевом уровне участвуют маршрутизаторы или полнофункциональные компьютеры, 
расположенные на маршруте сообщения. 


Примечание Предполагается наличие промежуточных маршрутизаторов, 
то есть сообщение не попадает сразу в конечный пункт. 
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Прикладной протокол 


Межсетевой 


уровень 
Интерфейсный С и -. Интерфейсный 


че чожеет ва 


Рис. 2.25. Сквозная связь 


Но промежуточные системы могут изменять некоторые поля, например, вре- 
мя существования датаграммы (ТТ. - Ите то Пуе) в [Р-заголовке. Поэтому меж- 
сетевой уровень в пункте назначения может «видеть» не в точности то же сообще- 
ние, что межсетевой уровень, который его послал. 

Этот подчеркивает различие между межсетевым и транспортным уровнями, 
Межсетевой уровень отвечает за доставку сообщений в следующий узел на марш- 
руте. И он общается с межсетевым уровнем именно этого узла, а не с межсетевым 
уровнем в конечной точке. Транспортные же уровни контактируют напрямую, не 
имея информации о существовании промежуточных систем. 


Резюме 


В этом разделе дано сравнение моделей ОЗТ и ТСР/ТР. Вы узнали, что семи- 
уровневая модель ОЗ] нужна как средство описания сетевой архитектуры, но со- 
зданные на ее базе реализации почти не имеют успеха. 


8) В В И О О ООО ОО ООО 


Глава 3. Создание эффективных 
и устойчивых сетевых программ 


Совет 15. Разберитесь с операцией записи в ТСР 


Здесь и далее обсуждаются некоторые особенности операций чтения и записи 
при программировании ТСР/[Р. Представляет интерес не конкретный АР! и дета- 
ли системных вызовов, а семантические вопросы, связанные с этими операциями. 

Как сказано в совете 6, между операциями записи и посылаемыми ТСР сег- 
ментами нет взаимно-однозначного соответствия. Как именно соотносятся обра- 
щения к операции записи с протоколом ТСР, зависит от системы, но все же специ- 
фикации протокола достаточно определенны и можно сделать некоторые выводы 
при знакомстве с конкретной реализацией. Традиционная реализация подробно 
описана в системе ВЗО. Она часто рассматривается как эталонная, и ее исходные 
тексты доступны. 


Примечание Исходные тексты оригинальной реализации для системы 
4.485)-Ше2 можно получить на СО-КОМ у компании Утш 
СтееЁ (р;// шишсатот.сот). Подробные пояснения к исход- 
ному тексту вы найдете в книге [УпЕЙ апа бееп$ 1995], 


Операция записи с точки зрения приложения 


Когда пользователь выполняет запись в ТСР-соединение, данные сначала ко- 
пируются из буфера пользователя в память ядра. Дальнейшее зависит от состоя- 
ния соединения. ТСР может «решить», что надо послать все данные, только часть 
или ничего не посылать. О том, как принимается решение, будет сказано ниже. 
Сначала рассмотрим операцию записи с точки зрения приложения. 

Хочется думать, что если операция записи п байт вернула значение п, то все 
эти п байт, действительно, переданы на другой конец и, возможно, уже подтверж- 
дены. Увы, это не так. ТСР посылает столько данных, сколько возможно (или ни- 
чего), и немедленно возвращает значение п. Приложение не определяет, какая 
часть данных послана и были ли они подтверждены. 

В общем случае операция записи не блокирует процесс, если только буфер пе- 
редачи ТСР не полон. Это означает, что после записи управление почти всегда 
быстро возвращается программе. После получения управления нельзя ничего га- 
рантировать относительно местонахождения «записанных» данных. Как упомина- 
лось в совете 9, это имеет значение для надежности передачи данных. 
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С точки зрения приложения данные записаны. Поэтому, помня о гарантиях 
доставки, предлагаемых ТСР можно считать, что информация дошла до другого 
конца. В действительности, некоторые (или все) эти данные в момент возврата из 
операции записи могут все еще стоять в очереди на передачу. И если хост или при 
ложение на другом конце постигнет крах, то информация будет потеряна. 


Примечание Если отправляющее приложение завершает сеанс аварийно, то 
ТСР все равно будет пытаться доставить данные. 


Еще один важный момент, который нужно иметь в виду, — это обработка ошиб- 
ки записи. Если при записи на диск вызов иг1 ее не вернул код ошибки, то точно 
известно, что запись была успешной. 


Дреиечание Строго говоря, это неверно. Обычно данные находятся в буфере 
в пространстве ядра до того момента, пока не произойдет сброс 
буферов на диск. Поэтому если до этого момента система «упа- 
дет», то данные вполне могут быть потеряны. Но суть в том 
что после возврата из иг1Ее уже не будет никаких сообщений об 
ошибках. Можно признать потерю не сброшенных на диск дан- 
ных неизбежной, но не более вероятной, чем отказ самого диска. 


При работе с ТСР получение кода ошибки от операции записи — очень редкое 
явление. Поскольку операция записи возвращает управление до фактической от- 
правки данных, обычно ошибки выявляются при последующих операциях, о чем 
говорилось в совете 9. Так как следующей операцией чаще всего бывает чтение 
предполагается, что ошибки записи обнаруживаются при чтении. Операция запи- 
си возвращает лишь ошибки, очевидные в момент вызова, а именно: 


о неверный дескриптор сокета; 

о файловый дескриптор указывает не на сокет (в случае вызова зепа и род- 
ственных функций); 

о указанный при вызове сокет не существует или не подсоединен; 

О вкачестве адреса буфера указан недопустимый адрес. 


Причина большинства этих проблем — ошибка в программе. После заверше- 
ния стадии разработки они почти не встречаются. Исключение составляет код 
ошибки ЕРТРЕ (или сигнал $ТСРТРЕ), который свидетельствует о сбросе соедине- 
ния хостом на другом конце. Условия, при которых такая ошибка возникает, об- 
суждались в совете 9 при рассмотрении краха приложения-партнера. 

Подводя итог этим рассуждениям, можно сказать, что применительно к ТСР- 
соединениям операцию записи лучше представлять себе как копирование в оче- 
редь для передачи, сопровождаемое извещением ТСР о появлении новых данных. 
Понятно, какую работу ТСР произведет дальше, но эти действия будут асинхрон- 
ны по отношению к самой записи. 


Операция записи с точки зрения ТСР 


Как отмечалось выше, операция записи отвечает лишь за копирование данных 
из буфера приложения в память ядра и уведомление ТСР о том, что появились 
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новые данные для передачи. А теперь рассмотрим некоторые из критериев, кото- 
рыми руководствуется ТСР «принимая решение» о том, можно ли передать новые 
данные незамедлительно и в каком количестве. Я не задаюсь целью полностью 
объяснить логику отправки данных в ТСР ахочу лишь помочь вам составить пред- 
ставление о факторах, влияющих на эту логику. Тогда вы сможете лучше понять 
принципы работы своих программ. 

Одна из основных Целей стратегии отправки данных в ТСР - максимально эф- 
фективное использование имеющейся полосы пропускания. ТСР посылает данные 
блоками, размер которых равен М$55 (тахипит зевтепа $12е — максимальный раз- 
мер сегмента). 


Примечание В процессе установления соединения ТСР на каждом конце мо- 
жет указать приемлемый для него М55. ТСР на другом коние 
обязан удовлетворить это пожелание и не посылать сегменты 
большего размера. М55 вычисляется на основе МТИ (тахиптит 
тапутзяоп ипй — максимальный размер передаваемого блока), 
как описано в совете 7. 


Вто же время ТСР не может переполнять буферы на принимающем конце. Как 
вы видели в совете 1, это определяется окном передачи. 

Если бы эти два условия были единственными, то стратегия отправки была бы 
проста: немедленно послать все имеющиеся данные, упаковав их в сегменты раз- 
мером М5$, но не более чем разрешено окном передачи. К сожалению, есть и дру- 
гие факторы. 

Прежде всего, очень важно не допускать перегрузки сети. Если ТСР неожи- 
данно пошлет в сеть большое число сегментов, может исчерпаться память марш- 
рутизатора, что повлечет за собой отбрасывание датаграмм. А из-за этого начнутся 
повторные передачи, что еще больше загрузит сеть. В худшем случае сеть будет 
загружена настолько, что датаграммы вообще нельзя будет доставить. Это называ- 
ется затором (сопезНоп соПарзе). Чтобы избежать перегрузки, ТСР не посылает 
по простаивающему соединению все сегменты сразу. Сначала он посылает один 
сегмент и постепенно увеличивает число неподтвержденных сегментов в сети, пока 
не будет достигнуто равновесие. 


Примечание Эту проблему можно наглядно проиллюстрировать таким при- 
мером. Предположим, что в комнате, полной народу, кто-то 
закричал: «Пожар!» Все одновременно бросаются к дверям, воз- 
никает давка, и в результате никто не может выйти. Если же 
люди будут выходить по одному, то пробки не возникнет, и все 
благополучно покинут помещение. 


Для предотврашения перегрузки ТСР применяет два алгоритма, в которых исполь- 
зуется еще одно окно, называемое окном перегрузки. Максимальное число байтов, 
которое ТСР может послать в любой момент, — это минимальная из двух величин: 
размер окна передачи и размер окна перегрузки. Обратите внимание, что эти окна 
отвечают за разные аспекты управления потоком. Окно передачи, декларируемое 
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ТСР на другом конце, предохраняет от переполнения его буферов. Окно перегруз- 
ки, отслеживаемое ТСР на вашем конце, не дает превысить пропускную способ- 
ность сети. Ограничив объем передачи минимальным из этих двух окон, вы удов- 
летворяете обоим требованиям управления потоком. 

Первый алгоритм управления перегрузкой называется «медленный старт». Он 
постепенно увеличивает частоту передачи сегментов в сеть до пороговой величины. 


Примечание Слово «медленный» взято в кавычки, поскольку на самом деле 
нарастание частоты экспоненциально. При медленном старте 
окно перегрузки открывается на один сегмент при получении 
каждого АСК. Если вы начали с одного сегмента, то последова- 
тельные размеры окна будут составлять 1, 2, 4, 8 ит.д. 


Когда размер окна перегрузки достигает порога, который называется порогом 
медленного старта, этот алгоритм прекращает работу, и в дело вступает алгоритм 
избежания перегрузки. Его работа предполагает, что соединение достигло равно- 
весного состояния, и сеть постоянно зондируется - не увеличилась ли пропускная 
способность. На этой стадии окно перегрузки открывается линейно - по одному 
сегменту за период кругового обращения. 

В стратегии отправки ТСР окно перегрузки в принципе может запретить посы- 
лать данные, которые в его отсутствие можно было бы послать. Если происходит 
перегрузка (о чем свидетельствует потерянный сегмент) или сеть некоторое время 
простаивает, то окно перегрузки сужается, возможно, даже до размера одного сег- 
мента. В зависимости от того, сколько данных находится в очереди, и сколько их 
пытается послать приложение, это может препятствовать отправке всех данных. 

Авторитетным источником информации об алгоритмах избежания перегрузки 
является работа []асоЪзоп 1988], в которой они впервые были предложены. Дже- 
кобсон привел результаты нескольких экспериментов, демонстрирующие замет- 
ное повышение производительности сети после внедрения управления перегруз- 
кой. В книге [З{еуепз 1994] содержится подробное объяснение этих алгоритмов 
и результаты трассировки в локальной сети. В настоящее время эти алгоритмы сле- 


дует включать в любую реализацию, согласующуюся со стандартом (КЕС 1122 
[Вга4деп 1989]. 


Примечание Несмотря на впечатляющие результаты, реализация этих ал- 
горитмов очень проста - всего две переменные состояния и не- 
сколько строчек кода. Детали можно найти в книге [та апа 
5{е0епз 1995], 


Еще один фактор, влияющий на стратегию отправки ТСР, - алгоритм Нейгла. 
Этот алгоритм впервые предложен в ВЕС 896 [Маше 1984]. Он требует, чтобы ни- 
когда не было более одного неподтвержденного маленького сегмента, то есть сег- 
мента размером менее М$$. Цель алгоритма Нейгла - не дать ТСР забить сеть пос- 
ледовательностью мелких сегментов. Вместо этого ТСР сохраняет в своих буферах 
небольшие блоки данных, пока не получит подтверждение на предыдущий малень- 
кий сегмент, после чего посылает сразу все накопившиеся данные. В совете 24 вы 
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увидите, что отключение алгоритма Нейгла может заметно сказаться на произво- 
дительности приложения. 

Если приложение записывает данные небольшими порциями, то эффект от ал- 
горитма Нейгла очевиден. Предположим, что есть простаивающее соединение, окна 
передачи и перегрузки достаточно велики, а выполняются подряд две небольшие 
операции записи. Данные, записанные вначале, передаются немедленно, поскольку 
окна это позволяют, а алгоритм Нейгла не препятствует, так как неподтвержденных 
данных нет (соединение простаивало). Но, когда до ТСР доходят данные, получен- 
ные при второй операции, они не передаются, хотя в окнах передачи и перегрузки 
есть место. Поскольку уже есть один неподтвержденный маленький сегмент, и алго- 
ритм Нейгла требует оставить данные в очереди, пока не придет АСК. 

Обычно при реализации алгоритма Нейгла не посылают маленький сегмент, 
если есть неподтвержденные данные. Такая процедура рекомендована КЕС 1122. 
Но реализация в ВЗО (и некоторые другие) несколько отходит от этого правила 
и отправляет маленький сегмент, если это последний фрагмент большой одновре- 
менно записанной части данных, а соединение простаивает. Например, М$$ для 
простаивающего соединения равен 1460 байт, а приложение записывает 1600 байт. 
При этом ТСР пошлет (при условии, что это разрешено окнами передачи и пере- 
грузки) сначала сегмент размером 1460, а сразу вслед за ним, не дожидаясь под- 
тверждения, сегмент размером 140. При строгой интерпретации алгоритма Ней- 
гла следовало бы отложить отправку второго сегмента либо до подтверждения 
первого, либо до того, как приложение запишет достаточно данных для формиро- 
вания полного сегмента. 

Алгоритм Нейгла - это лишь один из двух алгоритмов, позволяющих избе- 
жать синдрома безумного окна (5\\ 5 — зШу элпдо\ зуп4готе). Смысл этой так- 
тики в том, чтобы не допустить отправки небольших объемов данных. Синдром 
5/5 и его отрицательное влияние на производительность обсуждаются в ВЕС 813 
[ак 1982]. Как вы видели, алгоритм Нейгла пытается избежать синдрома $\/5 
со стороны отправителя. Но требуются и усилия со стороны получателя, который 
не должен декларировать слишком маленькие окна. 

Напомним, что окно передачи дает оценку свободного места в буферах хоста 
на другом конце соединения. Этот хост объявляет о том, сколько в нем имеется 
места, включая в каждый посылаемый сегмент информацию об обновлении окна. 
Чтобы избежать $\/$, получатель не должен объявлять о небольших изменениях. 

Следует пояснить это на примере. Предположим, у получателя есть 14600 сво- 
бодных байт, а М$$ составляет 1460 байт. Допустим также, что приложением на 
конце получателя читается за один раз всего по 100 байт. Отправив получателю 
10 сегментов, окно передачи закроется. И вы будете вынуждены приостановить от- 
правку данных. Но вот приложение прочитало 100 байт, в буфере приема 100 байт 
освободилось. Если бы получатель объявил об этих 100 байтах, то вы тут же послали 
бы ему маленький сегмент, поскольку ТСР временно отменяет алгоритм Нейгла, 
если из-за него длительное время невозможно отправить маленький сегмент. Вы 
и дальше продолжали бы посылать стобайтные пакеты, так как всякий раз, когда 
приложение на конце получателя читает очередные 100 байт, получатель объявляет 
об освобождении этих 100 байт, посылая информацию об обновлении окна. 
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Алгоритм избежания синдрома 5$\/5 на получающем конце не позволяет 
объявлять об обновлении окна, если объем буферной памяти значительно не уве- 
личился. В ВЕС 1122 «значительно» -— это на размер полного сегмента или более 
чем на половину максимального размера окна. В реализациях, производных от 
В$О, требуется увеличение на два полных сегмента или на половину максималь- 
ного размера окна. 

Может показаться, что избежание 3\/5$ со стороны получателя излишне (по- 
скольку отправителю не разрешено посылать маленькие сегменты), но в действи- 
тельности это защита от тех стеков ТСР/[Р в которых алгоритм Нейгла не реали- 
зован или отключен приложением (совет 24). ВЕС 1122 требует от реализаций 
ТСР удовлетворяющих стандарту, осуществлять избежание 5\/5 на обоих концах. 

На основе этой информации теперь можно сформулировать стратегию отправ- 
ки, принятую в реализациях ТСР, производных от В$О. В других реализациях 
стратегия может быть несколько иной, но основные принципы сохраняются. 

При каждом вызове процедуры вывода ТСР вычисляет объем данных, кото- 
рые можно послать. Это минимальное значение количества данных в буфере пере- 
дачи, размера окон передачи и перегрузки и М55. Данные отправляются при вы- 
полнении хотя бы одного из следующих условий: 


О можно послать полный сегмент размером М$5; 

О соединение простаивает, и можно опустошить буфер передачи; 

О алгоритм Нейгла отключен, и можно опустошить буфер передачи; 

О есть срочные данные для отправки; 

О есть маленький сегмент, но его отправка уже задержана на достаточно дли- 
тельное время; 


Примечание Если у ТСР есть маленький сегмент, который запрещено посы- 
лать, то он взводит таймер на то время, которое потребова- 
лось бы для ожидания АСК перед повторной передачей (но в пре- 
делах 5-60 с). Иными словами, устанавливается тайм-аут 
ретрансмиссии (ЕТО). Если этот таймер, называемый тайме- 
ром терпения (регя5Е итег), срабатывает, то ТСР все-таки по- 
сылает сегмент при условии, что это не противоречит ограниче- 
ниям, которые накладывают окна передачи и перегрузки. Даже 
если получатель объявляет окно размером нуль байт, ТСР все рав- 
но попытается послать один байт. Это делается для того, что- 
бы потерянное обновление окна не привело к тупиковой ситуации. 

Е 


О окно приема, объявленное хостом на другом конце, открыто не менее чем на- 
половину; 

о необходимо повторно передать сегмент; 

О требуется послать АСК на принятые данные; 

О нужно объявить об обновлении окна. 


Резюме 


Вэтом разделе подробно рассмотрена операция записи. С точки зрения прило- 
жения операцию записи проще всего представлять как копирование из адресного 
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пространства пользователя в буферы ядра и последующий возврат. Срок переда- 
чи данных ТСР и их объем зависят от состояния соединения, а приложение не 
имеет подобной информации. 

Проанализированы стратегия отправки, принятая в ВЗО ТСР а также влия- 
ние на нее объема буферной памяти у получателя (представлен окном Передачи), 
оценки загрузки сети (представлена окном перегрузки), объема данных, готовых 
для передачи, попытки избежать синдрома безумного окна и стратегии повторной 
передачи. 


Совет 16. Разберитесь с аккуратным размыканием 
ТСР-соединений 
Как вы уже видели, в работе ТСР-соединения есть три фазы: 


1. Установления соединения. 
2. Передачи данных. 
3. Разрыва соединения. 


Вэтом разделе будет рассмотрен переход от фазы передачи данных к фазе раз- 
рыва соединения. Точнее, как узнать, что хост на другом конце завершил фазу пе- 
редачи данных и готов к разрыву соединения, и как он может сообщить об этом 
партнеру. 

Вы увидите, что один хост может прекратить отправку данных и сигнализиро- 
вать партнеру об этом, не отказываясь, однако, от приема данных. Это возможно, 
поскольку ТСР-соединения полнодуплексные, потоки данных в разных направле- 
ниях не зависят друг от друга. 

Например, клиент может соединиться с сервером, отправить серию запросов, 
а затем закрыть свою половину соединения, предоставив тем самым серверу ин- 
формацию, что больше запросов не будет. Серверу для ответа клиенту, возможно, 
понадобится выполнить большой объем работы и даже связаться с другими серве- 
рами, так что он продолжает посылать данные уже после того, как клиент прекра- 
тил отправлять запросы. С другой стороны, сервер может послать в ответ сколько 
угодно данных, так что клиент не определяет заранее, когда ответ закончится. По- 
этому сервер, вероятно, как и клиент, закроет свой конец соединения, сигнализи- 
руя о конце передачи. 

После того как ответ на последний запрос клиента отправлен и сервер закрыл 
свой конец соединения, ТСР завершает фазу разрыва. Обратите внимание, что за- 
крытие соединения рассматривается как естественный способ известить партне- 
рао прекращении передачи данных. По сути, посылается признак конца файла ЕОЕ 


Вызов 5пищоип 


Как приложение закрывает свой конец соединения? Оно не может просто за- 
вершить сеанс или закрыть сокет, поскольку у партнера могут быть еще данные. 
В АР! сокетов есть интерфейс знаеао"т. Он используется так же, как и вызов 
с1озе, но при этом передается дополнительный параметр, означающий, какую сто- 
рону соединения надо закрыть. 
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#10с14аае <зуз/зоскее.й> /* ПОМТХ. */ 
#11с1аае <изпзоск2.1> /* Мзпаомз. */ 


зрЕ зриЕаомп( 110Е 3, апЕЁ Бой }; /* ОМТХ. */ 
ПЕ эВиЕаомт ( бОСКЕТ з, 1пЕ Бом }; /* И1паомз. */ 


Возвращаемое значение: 0 - нормально, —1 (ОМХ) или ЗОСКЕТ_ЕКВОВ 
(УЛп4о\з) — ошибка. 


К сожалению, между реализациями эпаедомт в ОШХ и УЛпдо\$ есть разли- 
чия в семантике и АР]. Традиционно в качестве значений параметра Вом вызова 
знаЕаомт использовались числа. И в стандарте РОЗ[Х, и в спецификации УЛизосК 
им присвоены символические имена, только разные. В табл. 3.1 приведены значе- 
ния, символические константы для них и семантика параметра ром. 

Различия в символических именах можно легко компенсировать, определив 
в заголовочном файле одни константы через другие или используя числовые зна- 
чения. А вот семантические отличия гораздо серьезнее. Посмотрим, для чего пред- 
назначено каждое значение. 


Таблица 3.1. Значения параметра Пом/ для вызова звиЮоитп 


Значение Пом 


Числовое РОЗХ — МИпвоск НствиЯ 

0 ЗНУТ_АО $0_ВЕСЕМЕ Закрывается принимающая сторона соединения 
1 ЗНЧТ МВ $0_$ЗЕМО Закрывается передающая сторона соединения 
2 ЗНУТ_АБ\М/А $0_ВОТН Закрываются обе стороны 


Вой = 0 Закрывается принимающая сторона соединения. В обеих реализациях 
в сокете делается пометка, что он больше не может принимать данные 
и должен вернуть ЕОЁ если приложением делаются попытки еще что- 
то читать. Но отношение к данным, уже находившимся в очереди при- 
ложения в момент выполнения эВ Яоут, а также к приему новых дан- 
ных от хоста на другом конце различное. В МХ все ранее принятые, 
но еще не прочитанные данные уничтожаются, так что приложение их 
уже не получит. Если поступают новые данные, то ТСР их подтверж- 
дает и тут же отбрасывает, поскольку приложение не хочет принимать 
новые данные. Наоборот, в соответствии с УЛпзосК соединение вообще 
разрывается, если в очереди есть еще данные или поступают новые. 
Поэтому некоторые авторы (например, [Ошшпп ап4 ЗВще 1996]) счита- 
ют, что под \Ип4о\з использование конструкции 


эзпабаомт (в, 0); 


небезопасно. 

вом = 1 Закрывается отправляющая сторона соединения. В сокете делается по- 
метка, что данные посылаться больше не будут; все последующие по- 
пытки выполнить для него операцию записи заканчиваются ошибкой. 
После того как вся информация из буфера отправлена, ТСР посылает 
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сегмент ЕТМ, сообщая партнеру, что данных больше не будет. Это называ- 
ется полузакрытием (БаЁ с1ое). Такое использование вызова зпоЕЯоит 
наиболее типично, и его семантика в обеих реализациях одинакова. 

ром = 2 Закрываются обе стороны соединения. Эффект такой же, как при вы- 
полнении вызова зпоЕЯомпт дважды, один раз с Вои = 0, а другой — 
с Бои = 1. Хотя, на первый взгляд, обращение 


зрабдома( 5, 2); 


эквивалентно вызову с1озе или с1озезоскКее, в действительности это 
не так. Обычно нет причин для вызова эНаЕЯо\ит с параметром пои= 2, но 
в работе [Ошшп апа ЗВце 1996] сообщается, что в некоторых реализациях 
М/пзосК вызов с1озезосКеЕ работает неправильно, если предварительно 
не было обращения к зБаЕ отт с Вои = 2. В соответствии с УЛпзоск вы- 
зов зВчЕЯотт с Вои = 2 создает ту же проблему, что и вызов с Бои = 0, — 
может быть разорвано соединение. 


Между закрытием сокета и вызовом зВаЕЗомт есть существенные различия. 
Во-первых, зВабаоит не закрывает сокет по-настоящему, даже если он вызван 
с параметром 2. Иными словами, ни сокет, ни ассоциированные с ним ресурсы (за 
исключением буфера приема, если Ром = 0 или 2) не освобождаются. Кроме того, 
воздействие за Яо\мт распространяется на все процессы, в которых этот сокет от- 
крыт. Так, например, вызов зпаЕ доп с параметром ром = 1 делает невозможной 
запись в этот сокет для всех его владельцев. При вызове же с1озе или с1озезоскее 
все остальные процессы могут продолжать пользоваться сокетом. 

Последний факт во многих случаях можно обратить на пользу. Вызывая за Зоит 
с Вои = 1, будьте уверены, что партнер получит ЕОЕЁ даже если этот сокет открыт 
и другими процессами. При вызове с1озе или с1озезоскее это не гарантируется, 
поскольку ТСР не пошлет ЕТ\, пока счетчик ссылок на сокет не станет равным 
нулю. А это произойдет только тогда, когда все процессы закроют этот сокет. 

Наконец, стоит упомянуть, что, хотя в этом разделе говорится о ТСР, вызов 
зВаЕаомт применим ик ОБР Поскольку нет соединения, которое можно закрыть, 
польза обращения к зп доут с Бои = 1 или 2, остается под вопросом, но задавать 
параметр Бои = 0 можно для предотвращения приема датаграмм из конкретного 
ОБР-порта. 


Аккуратное размыкание соединений 


Теперь, когда вы познакомились с вызовом эра Яоута, посмотрите, как его мож- 
но использовать для аккуратного размыкания соединения. Цель этой операции -— 
гарантировать, что обе стороны получат все предназначенные им данные до того, 
как соединение будет разорвано. 


Примечание Термин ‹аккуратное размыкание» (от4епу тёеазе) имеет неко- 
торое отношение к команде Е_вп@ге1 из АР] ХЛ] (совет 5), кото- 
рую также часто называют аккуратным размыканием в отличие 
от команды грубого размыкания (афотйе теа5е) Е_эпаа1в. Но 
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путать их не стоит. Команда Е_впаге1 выполняет те же дей- 
ствия, что и вВиЕаойт. Обе команды используются для акку- 
ратного размыкания соединения. 


Просто закрыть соединение в некоторых случаях недостаточно, поскольку 
могут быть потеряны еще не принятые данные. Помните, что, когда приложение 
закрывает соединение, недоставленные данные отбрасываются. 

Чтобы поэкспериментировать с аккуратным размыканием, запрограммируй- 
те клиент, который посылает серверу данные, а затем читает и печатает ответ сер- 
вера. Текст программы приведен в листинге 3.1. Клиент читает из стандартного 
входа данные для отправки серверу. Как только Ёдеез вернет МОТ, индицирую- 
щий конец файла, клиент начинает процедуру разрыва соединения. Параметр -с 
в командной строке управляет этим процессом. Если -с не задан, то программа 
эра аомпс вызывает эра Яомт для закрытия передающего конца соединения. 
Если же параметр задан, то зниЕаомпс вызывает СПО$Е, затем пять секунд 
«спит» и завершает сеанс. 


Листинг 3. 1. Клиент для экспериментов с аккуратным размыканием 


Ва аомтс . с 
1 Нис1аае "еёср.в" 
2 1пЕ па1п( 116 агас, спахг **акау ) 
9 
4 ЗОСКЕТ з; 
5 Еа_зее геаЯптазк; 
6 Еа_зее а11геа@з; 
7 ТАЕ те; 
8 106 1еп; 
9 116 с; 
10 106 с1озе1е = КАГЗЕ; 
11 106 егг = ЕАГЗЕ; 
12 спаг 111[ 1024 ]; 
13 СПаг 1оцЕ[ 1024 }; 


14 тмтт(); 

15 орбегг = КАПШСЕ; 

16 У11е ( (с = деборЕ( агас, агау, "с" ) ) != ЕОЕ ) 
17 { 

18 ВиТЕСАЕ С} 

19 { 

20 сазе ‘'с' 

21 с1озе1Е = ТВОЕ; 

22 Ьгеак; 

23 сазе '?' 

24 егхг = ТВОЕ; 

25 } 

26 } 

27 1Е ( егк || агас - орб1та 1= 2) 

28 еггог( 1, 0, "Порядок вызова: %$ [-с] хост порт\п", 


29 ргодгам_паме }; 


Аккуратное размыкание ТСР-соединений М 


30 3 = Еср с11епё( агау[ орЕе1па ], агау[ орбша +1] )}; 


31 ЕО _2ЕКО( &а11]геа@$ ); 
32 ЕО _ЗЕТ( 0, &а1]геааз }; 
33 ЕО _ЗЕТ( 3, &а]1геааз }; 


34 Рог (;; ) 
35 { 
36 геадтазкК = а1]1геа@з; 
37 гс = зе1]есе( зв + 1, &геаатавк, №, МОБ, МЛЯ, ); 
38 1Е (гс <=0 ) 
39 еггог( 1, еггпо, "ошибка: зсе1есЕ вернул (%4а)", гс }; 
40 1Е ( ЕО Т5У5ЕТ( <, &геа@тазКк } } 
41 { 
42 гс = гесу( в, 111, °12еоЁ( 111 ) - 1,0}; 
43 1Е (тс <0) 
44 еггог( 1, еггкпо, "ошибка вызова гесу" }; 
45 ТЕ (тс == 0) 
46 еггог( 1, 0, "сервер отсоединился\п" }; 
47 110[ кс ] = '\0'; 
48 1Е ( Ерцёз( 11п, зЕбодЕ ) == БОР ) 
49 еггог( 1, еггпо, "ошибка вызова Ёраёз" }; 
50 } 
51 1Е ( ЕО Т55ЗЕТ( 0, &геаамазк ) ) 
5:2 { 
53 1Е ( Едебз®( 1ом6, з12еоЁ( 104 ), вет } == М, ) 
54 { 
55 РО _СЬВ( 0, &а11геааз }; 
56 1Е ( с1озе1Е } 
57 { 
58 СЬО5Е{ $ }; 
59 $1еер{ 5 ); 
60 ЕХТТа 0) 
61 } 
62 е1зе 1Е ( зпабЯдот (5,1) ) 
63 еггог( 1, еггпо, "ошибка вызова зПабао%ут" ); 
64 } 
65 е]1зе 
66 { 
67 1еп = з6г]еп( 1016 ); 
68 ГС = зерЯ( з, 1оцЕ, 1еп, 0}; 
69 Е (ке 0) 
70 еггог( 1, еггио, "ошибка вызова зепа" ); 
71 } 
72 } 
48 } 
74 } 
эра Яао%\тс. с 
Инициализация 


14-30 Выполняем обычную инициализацию клиента и проверяем, есть ли 
в командной строке флаг -с. 


ГУЖМИШИИШИЕ! — Создание эффективных сетевых программ 


Обработка данных 

40-50 Если в ТСР-сокете есть данные для чтения, программа пытается про- 
читать, сколько можно, но не более, чем помещается в буфер. При по- 
лучении признака конца файла или ошибки завершаем сеанс, в против- 
ном случае выводим все прочитанное на зе Ч9оце. 


Примечание Обратите внимание на конструкцию э12еоЕ( 11п } -1 в вызове 
гесу на строке 42. Вопреки всем призывам избегать переполне- 
ния буфера, высказанным в совете 11, в первоначальной версии 
этой программы было написано 512еоЕ( 11п }, что привело 
к записи за границей буфера в операторе 


Па[ кс ] = '\0:; 


в строке 47. 


53-64 Прочитав из стандартного входа ЕОЕ, вызываем либо зНаЕЯоит, либо 
СЬОБЕ в зависимости от наличия флага -с. 
65-71 В противном случае передаем прочитанные данные серверу. 


Можно было бы вместе с этим клиентом использовать стандартный системный 
сервис эхо-контроля, но, чтобы увидеть возможные ошибки и ввести некоторую за- 
держку, напишите собственную версию эхо-сервера. Ничего особенного в програм- 
ме Есресро .с нет. Она только распознает дополнительный аргумент в командной 
строке, при наличии которого программа «спит» указанное число секунд между 
чтением и записью каждого блока данных (листинг 3.2). 

Сначала запустим клиент зна аомтс с флагом -с, чтобы он закрывал сокет 
после считывания ЕР из стандартного ввода. Поставим в сервере Е сресро задерж- 
Ку на 4 с перед отправкой назад только прочитанных данных: 


ЬзЯ: $ ЕсресВо 9000 4 & 


[1] 3836 

Ьза: $ вЬаеаомтс -с 1оса1Вове 9000 

ЯЧаЕа1 Эти три строки были введены 
ЯЧафса2 подряд максимально быстро 
^о 

СсресНо: ошибка вызова зеп@а: ВгоКкеп р1ре (32) Спустя 4 с 


после отправки "ЯаЁа1". 


Листинг 3.2. Эхо-сервер на базе ТСР 


ссреспо.с 
1 #1пс1аае "еёср.В" 


2 106 па1п( 106 агас, сраг **агау ) 


Вл 

4 ЗОСКЕТ <; 

5 ЗОСКЕТ $1; 

6 сраг БаЕ[ 1024 |; 
7 116 гс; 


Аккуратное размыкание ТСР-соединенни_ — 999 АСУТЕ 


8 11Е пар = 0; 


9 тмГТ(); 
10 1Е ( агас == ) 
11 пар = аёо1( агау[ 2] ); 


12 в = Есср_зегуег( МОШЬ, агкау[ 1 ] }); 

13 91 = ассере( $®, Ш, М ); 

14 ДЕ ( 1!13уа11авосКк( э1 ) ) 

15 еггог( 1, екггпо, "ошибка вызова ассерёе" ); 

16 з19па1( УТСРТРЕ, $ТС_ТСМ }; /* Игнорировать сигнал УТСРТРЕ. */ 
17 Еох’ (;; ) 


18 { 

19 гс = гесу( °1, БаЁ, $12еоЁ( БаЕЁ ), 0); 

20 1Е (кс == 0) 

21 еггог( 1, 0, "клиент отсоединился\п" }; 
22 1Е (тс < 0) 

23 еггог( 1, еггпо, "ошибка вызова гес\у" ); 
24 1Е ( пар ) 

я 31еер( пар ); 

26 гс = зепа( °1, БцЁ, гс, 0}; 

27 ТЕ те. 0 

28 еггог( 1, еггпо, "ошибка вызова зеп@а" )}; 
29 } 

30 } 


ссреспо.с 


Затем нужно напечатать две строки дав а1 и дава2 и сразу вслед за ними на- 
жать комбинацию клавиш Си]+), чтобы послать программе зВоЕЯомтс конец 
файла и вынудить ее закрыть сокет. Заметьте, что сервер не вернул ни одной стро- 
ки. В напечатанном сообщении Е сресНо об ошибке говорится, что произошло. 
Когда сервер вернулся из вызова з1еер и попытался отослать назад строку дака1, 
он получил ВЪТ, поскольку клиент уже закрыл соединение. 


Примечание Как объяснялось в совете 9, ошибка возвращается при записи 
второй строки (ааЕа2). Заметьте, что это один из немногих 
случаев, когда ошибку возвращает операция записи, а не чтения. 
Подробнее об этом рассказано в совете 15. 


В чем суть проблемы? Хотя клиент сообщил серверу о том, что больше не бу- 
дет посылать данные, но соединение разорвал до того, как сервер успел завершить 
обработку, в результате информация была потеряна. В левой половине рис. 3.2 по- 
казано, как происходил обмен сегментами. 

Теперь повторим эксперимент, но на этот раз запустим зваедомис без флага -с. 


Ьза: $ ЕсресВо 9000 4 & 

[1] 3845 

Ьза: $ врабаомас 1оса1ВовЕ 9000 
дафа1 

ЯЧабса2 

^р 
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даба1 Спустя 4 с после отправки "ЯЧаёЁа1". 
Ядаба2 Спустя 4 с после получения "ЧаЁа]1". 
ссресво: клиент отсоединился 

зрабЯомпс: сервер отсоединился 


Наэтот раз все сработало правильно. Прочитав из стандартного входа признак кон- 
ца файла, эпаедомтс вызывает зна онт, сообщая серверу, что он больше не будет 
ничего посылать, но продолжает читать данные из соединения. Когда сервер ЕсресНо 
обнаруживает ЕОЕ, посланный клиентом, он закрывает соединение, в результате чего 
ТСР посылает все оставшиеся в очереди данные, а вместе с ними ЕПМ. Клиент, полу- 
чив ЕОЕ, определяет, что сервер отправил все, что у него было, и завершает сеанс. 

Заметьте, что у сервера нет информации, какую операцию (зваЕЯоит или с1озе) 
выполнит клиент, пока не попытается писать в сокет и не получит код ошибки или 
ЕОР. Как видно из рис. 3.1, оба конца обмениваются теми же сегментами, что 
и раньше, до того, как ТСР клиента ответил на сегмент, содержащий строку дака1. 

Стоит отметить еще один момент. В примерах вы несколько раз видели, что, 
когда ТСР получает от хоста на другом конце сегмент Е1М, он сообщает об этом 
приложению, возвращая нуль из операции чтения. Примеры приводятся в строке 
45 листинга 3.1 и в строке 20 листинга 3.2, где путем сравнения кода возврата гесу 
с нулем проверяется, получен ли ЕОЕ. Часто возникает путаница, когда в ситуации 
подобной той, что показана в листинге 3.1, используется системный вызов зе1есё 
Когда приложение на другом конце закрывает отправляющую сторону соедине- 
ния, вызывая с1озе или зНаедомт либо просто завершая работу, зе1ес® возвра- 
щает управление, сообщая, что в сокете есть данные для чтения. Если приложение 
при этом не проверяет ЕОЕ, то оно может попытаться обработать сегмент нулевой 
длины или зациклиться, переключаясь между вызовами геаа и зе1есе. 

В сетевых конференциях часто отмечают, что «зе1еск свидетельствует о на- 
личии информации для чтения, но в действительности ничего не оказывается». 
В действительности хост на другом конце просто закрыл, как минимум, отправля- 
ющую сторону соединения, и данные, о присутствии которых говорит зе1еск, — 
это всего лишь признак конца файла. 


Резюме 


Вы изучили системный вызов зНаЕдо"т и сравнили его с вызовом с1озе. Так- 
же рассказывалось, что с помощью эВаедомт можно закрыть только отправляю- 
щую, принимающую или обе стороны соединения; и счетчик ссылок на сокет при 
этом изменяется иначе, чем при закрытии с помощью с1о5е. 

Затем было показано, как использовать зНаЕдоит для аккуратного размыка- 
ния соединения. Аккуратное размыкание - это последовательность разрыва соеди- 
нения, при которой данные не теряются. 


Совет 17. Подумайте о запуске своего приложения 
через те 


В операционной системе ОМШХ и некоторых других имеется сетевой супер- 
сервер 3пеё 9, который позволяет почти без усилий сделать приложение сетевым 


Запуск приложения через те"4 11111] | |145. 


зВабао%тс Есреспо 5рабаомпс Есресво 


Зав 1 Ча 1 


сю5е Зиомтп 


а 
отн: 
= 
зн ЗИИЙ 


Соединение разомкнуто 
с помощью зпиомт 


Рис. 3.1. Системные вызовы с/о$е и зниоит 


Кроме того, если есть всего один процесс, который прослушивает входящие соеди- 
нения и входящие ОЮР-датаграммы, то можно сэкономить системные ресурсы. 

Обычно 1пеЕ а поддерживает, по меньшей мере, протоколы ТСР и ОПР а возмож- 
но, и некоторые другие. Здесь будут рассмотрены только два первых. Поведение 1пеёа 
существенно зависит от того, с каким протоколом — ТСР или ОПР - он работает. 


ТСР-серверы 


Для ТСР-серверов 1 пе прослушивает хорошо известные порты, ожидая за- 
проса на соединение, затем принимает соединение, ассоциирует с ним файловые 
дескрипторы з91п, зЕдоце и зЕдегг, после чего запускает приложение. Таким 
образом, сервер может работать с соединением через дескрипторы 0, 1 и 2. Если 
это допускается конфигурационным файлом 1пее а (/езс/1пека. сопЕ), то 1пеЕ@ 


О-ВА ИОВА ШИ ШИ И — Создание эффективных сетевых программ 


продолжает прослушивать тот же порт. Когда в этот порт поступает запрос на но- 
вое соединение, запускается новый экземпляр сервера, даже если первый еще не 
завершил сеанс. Это показано на рис. 3.2. Обратите внимание, что серверу не 
нужно обслуживать нескольких клиентов. Он просто выполняет запросы одного 
клиента, а потом завершается. Остальные клиенты обслуживаются дополнитель- 
ными экземплярами сервера. 


1песа (рагеп{) 


Еог (еасП зег\у1се) 


{ 
зоскКееЕ (} 
Ь1па() 
]1зЕеп() 


зе1есе() 
3 = ассере () 
ЕокКк () 

с1озе(з) 


1реба (спйа) 


ог (ореп ЕЯ != $8) 
с1озе (Еа) 
Зара (3,0) 
ара (3,1) 
Япр2 (3,2) 
с1о5е($) 
ехес()} 


Зегуег (спа) 


Рис. 3.2. Действия пеЮ при запуске ТСР-сервера 


Применение 1пеЕ& освобождает от необходимости самостоятельно устанав- 
ливать ТСР или ОО,Р-соединение и позволяет писать сетевое приложение почти 
так же, как обычный фильтр. Простой, хотя и не очень интересный пример при- 
веден в листинге 3.3. 


Листинг 3.3. Программа Ппита для подсчета строк 


ты г]пита. с 
1 #1ипс1аае <з6З1о.8> 
2 уо1а палзп( ухола ) 


С 
4 тие сое = 0; 

5 свахг 11пе[ 1024 }; 

6 /* 

7 * Мы должны явно установить режим построчной буФферизации, 

8 * так как фуниции из библиотеки стандартного ввода/вывода 
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9 * не считают сокет терминалом. */ 
10 зебсураЕ ( зЕаоцЕ, МОЬЬ, _ТОЬВЕ, 0}; 
у Ур11е ( Едеёз( 11пе, з12еоЁ( 11пе }), зЕаш } != М. ) 
12 ретпЕЁЕ( "%31: %5", ++спЕ, 1110е ); 
13} 


г]пита. с 
По поводу этой программы стоит сделать несколько замечаний: 


о втексте программы не упоминается ни о ТСР, ни вообще о сети. Это не зна- 
чит, что нельзя выполнять связанные с сокетами вызовы (деереегпаме, 
[93] еезоскор* ит.д.), просто в этом не всегда есть необходимость. Нет ника- 
ких ограничений и на использование геаЯ име е. Кроме того, можно пользо- 
ваться вызовами зепд, гес\, зепдко и гесуЁгон, как если бы 1пе% 4 не было. 

О режим буферизации строк приходится устанавливать самостоятельно, по- 
скольку стандартная библиотека ввода/вывода автоматически устанавлива- 
ет подобный режим только в том случае, если считает, что вывод произво- 
дится на терминал. Это позволяет обеспечить быстрое время реакции для 
интерактивных приложений; 

О стандартная библиотека берет на себя разбиение входного потока на строки. 
Об этом уже говорилось в совете 6; 

о предполагаем, что не будет строк длиннее 1023 байт. Более длинные строки 
будут разбиты на несколько частей, и у каждой будет свой номер; 


Примечание Этот факт, который указан в книге [ОШоет 2000], служит еще 
одним примером того, как можно легко допустить ошибку пере- 
полнения буфера. Подробнее этот вопрос обсуждался в совете 11. 


О хотя это приложение тривиально, но во многих «настоящих» ТСР-прило- 
жениях, например {епеф, Поз1п и Ёр, используется такая же техника. 


Программа в листинге 3.3 может работать и как «нормальный» фильтр, и как 
удаленный сервис подсчета строк. Чтобы превратить ее в удаленный сервис, нуж- 
но только выбрать номер порта, добавить в файл /еёс/зехг\1сез строку с именем 
сервиса и номером порта и включить в файл /еёс/1пеЕ@. сопЕЁ строку, описываю- 
щую этот сервис и путь к исполняемой программе. Например, если вы назовете 
сервис г1пим, исполняемую программу для него — г] пила и назначите ему порт 
8000, то надо будет добавить в /еёс/зегу1сез строку 


г] пом 8000/Еср # удаленный сервис подсчета строк, 
ав /еёс/1пеЕа. сопЕ — строку 
г]пом з6геам Еср пома1Е 3с3з /изг/Воте/3с®/к1]пиама к]пима. 


Добавленная в /еЕс/зеку1сез строка означает, что сервис х1пам использует 
протокол ТСР по порту 8000. Смысл же полей в строке, добавленной в /еёс/ 
1пеба. сопЕ, таков: 


О имя сервиса, как он назван в /еёс/зегу1сез. Это имя хорошо известного 
порта, к которому подсоединяются клиенты данного сервера. В вашем при- 
мере — х1 пам; 


ЕУИИ ВОВЕ — Создание эффективных сетевых программ 

О тип сокета, который нужен серверу. Для ТСР-серверов это з&геап, а для 
ООР-серверов — дагам. Поскольку здесь сервер пользуется протоколом ТСР 
указан з&геам; 

О протокол, применяемый с сервером, — Е ср или чар. В данном примере это & ср; 

О флаг ма1* /пома1®. Для ЧОР-серверов его значение всегда па1*, а для ТСР- 
серверов — почти всегда пома1&. Если задан флаг пома1*, то 1пееа сразу 
после запуска сервера возобновляет прослушивание связанного с ним хоро- 
шо известного порта. Если же задан флаг ма1*, то 1пеЕ@ не производит ника- 
кой работы с этим сокетом, пока сервер не завершится. А затем он возобновляет 
прослушивание порта в ожидании запросов на новые соединения (для ${геат- 
серверов) или новых датаграмм (для 4егат-серверов). Если для $4геат-серве- 
ра задан флаг ма1*, то 1пееа не вызывает ассер{ для соединения, а переда- 
ет сокет, находящийся в режиме прослушивания, самому серверу, который 
должен принять хотя бы одно соединение перед завершением. Как отмечено 
в сообщении [КасКег 1998], задание флага ма1® для ТСР-приложения - это 
мощная, но редко используемая возможность. Здесь приводится несколько 
применений флага ма1& для ТСР-соединений: 


— в качестве механизма рестарта для ненадежных сетевых программ-де- 
монов. Пока демон работает корректно, он принимает соединения от 
клиентов, но если по какой-то причине демон «падает», то при следую- 
щей попытке соединения 1пеЕ Я его рестартует; 

— как способ гарантировать одновременное подключение только одного 
клиента; 

— как способ управления многопоточным или многопроцессным приложе- 
нием, зависящим от нагрузки. В этом случае начальный процесс запус- 
кается 1пеба, а затем он динамически балансирует нагрузку, создавая 
по мере необходимости дополнительные процессы или потоки. При 
уменьшении нагрузки, потоки уничтожаются, а в случае длительного 
простоя завершает работу и сам процесс, освобождая ресурсы и возвра- 
щая прослушивающий сокет 1пеё 9. 


В данном примере задан флаг пома1*, как и обычно для ТСР-серверов. 


о имя пользователя, с правами которого будет запущен сервер. Это имя долж- 
но присутствовать в файле /еёс/раззма. Большинство стандартных серве- 
ров, прописанных в 1пеба. сопЕ, запускаются от имени гоок, но это совер- 
шенно необязательно. Здесь в качестве имени пользователя выбрано )сз. 

О полный путь к файлу исполняемой программы. Поскольку г1пиюЯ находит- 
ся в каталоге пользователя }сз, задан путь /азг/Ноше/)сз/хг1пима; 

О до пяти аргументов (начиная с агау [0] ), которые будут переданы серверу. По- 
скольку в этом примере у сервера нет аргументов, оставлен только агау [0}. 


Чтобы протестировать сервер, необходимо заставить 1пес а перечитать свой 
конфигурационный файл (в большинстве реализаций для этого нужно послать ему 
сигнал стснор) и соединиться с помощью Ее1пеё: 


Ьза: $ се1пес 1оса]1Вове храм 
Тута 127.0.0.1... 
СоппесбеЯ Ео 1оса1позЕ 


Запуск приложения через те 11111 | |149 


Езсаре свагасеег 15 "^]". 
Ве1]о 
1: Ве11о 
муог1а 
2: могла 
й] 
се1пеё> аи1& 
СоппесЕ1оп с1озеа. 
рза: $5 


ООР-серверы 

Поскольку в протоколе ОПР соединения не устанавливаются (совет 1), 1пеЕ Я 
нечего слушать. При этом 1пеё Я запрашивает операционную систему (с помощью 
вызова зе1ес®) о приходе новых датаграмм в порт ООР-сервера. Получив извеще- 
ние, 1 пед дублирует дескриптор сокета на Е 41п, зЕ доче и эк аегк и запускает 
ООР-сервер. В отличие от работы с ТСР-серверами при наличии флага помалк, 
: пеёа больше не предпринимает с этим портом никаких действий, пока сервер не 
завершит сеанс. В этот момент он снова предлагает системе извещать его о новых 
датаграммах. Прежде чем закончить работу, серверу нужно прочесть хотя бы одну 
датаграмму из сокета, чтобы 1пеЕ@ не «увидел» то же самое сообщение, что и рань- 
ше. В противном случае он опять запустит сервер, войдя в бесконечный цикл. 

Пример простого ООР-сервера, запускаемого через 1пеба, приведен в листинге 3.4. 
Этот сервер возвращает то, что получил, добавляя идентификатор своего процесса. 


Листинг 3.4. Простой сервер, реализующий протокол запрос-ответ 


царесро1.с 
1 Я пс1аае "ебср.й" 
2 11Е мало( 106 агос, саг **агау ) 
9 
4 зЕкгисЕ зоскКаЯЯх_1п реег; 
5 106 гс; 
6 116 1еп; 
7 116 р1@957; 
8 сваг БаЕ[ 120 |]; 
9 р1Я52 = эзрглпЕЕ( БаЕЁ, "%Аа: ", адебр1а() ); 
10 1еп = $12еоЁ( реег ); 
11 гс = гесуЁхгой( 0, БаЕЁ + р19587, з12еоЁ( БаЕЁ } - р1@ав2, 0, 
12 ( зЕкисЕе зоскКа@ахг * )&реег, &1еп ); 
13 1Е ( хс <= 0) 
14 ех1 (1 ); 
15 зепабо( 1, БЕ, гс + р1@52, 0, 
16 ( зЕгисЕ зоскКа@аг * })&реег, 1еп ); 
17 ех1Е (0); 
18 } 
иресНо1.с 
ирдесво1 
9 Получаем идентификатор процесса сервера (РГ) от операционной 


системы, преобразуем его в код АЗСП и помещаем в начало буфера вво- 
да/вывода. 


Создание эффективных сетевых программ 


10-14 Читаем датаграмму от клиента и размещаем ее в буфере после иденти- 
фикатора процесса. 
15-17 Возвращаем клиенту ответ и завершаем сеанс. 


Для экспериментов с этим сервером воспользуемся простым клиентом, код 
которого приведен в листинге 3.5. Он читает запросы из стандартного ввода, отсы- 
лает их серверу и печатает ответы на стандартном выводе. 


Листинг 3.5. Простой ЦОР-клиент 


цнарс11епёЕ.с 


1 #1ис1аае "ебср.В" 

2 1иЕ пал1п( 116 агас, сраг **агау ) 

В 

4 зегисЕ зоскаа@аг_1п реег; 

5 СОСКЕТ $; 

6 106 гс = 0; 

7 106 1еп; 

8 срах БаЕ[ 120 1; 

9 МТТ); 

10 3 = цар_с11епе( акау[ 1 ], агау[ 2 |], &реег }; 

11 р11е ( Едебз( ЪиЁ, з12еоЁ( ЪаЕ ), зат ) != МЫ, ) 
12 { 
13 гс = зепабо( $, БаЁ, эзбг1еп( БоаЕЁ ),О0, 
14 ( <ЕкисЕ зоска@аг * )&реег, з1хеоЁ( реег ) ); 
15 1Е (тс < 0) 
16 еггох( 1, еггпо, "ошибка вызова зепаво" )}; 
17 1еп = з12еоЕ( реег }; 
18 гс = гесуЁгом( $з, РаЁ, з17еоЕЁ( РыЕЁ } - 1, 0, 

19 ( зскосЕ зоскаааг * )бёреег, &1еп }; 
20 1Е (тс < 0) 
21 еггог( 1, егхгпо, "ошибка вызова гесуУуЁгкот" ); 


22 БЕГ хе |= "\0"; 


23 Ерибз( раЕЁ, $зЕ9оцЕ ); 
24А } 
25 ЕХТТ( О ); 
26 } 
парс11епЕ.с 
10 Вызываем функцию цар_с11епе, чтобы она поместила в структуру 


реег адрес сервера и получила ООР-сокет. 

11-16 Читаем строку из стандартного ввода и посылаем ее в виде ООР-дата- 
граммы хосту и в порт, указанные в командной строке. 

17-21 Вызываем кесуЁкоп для чтения ответа сервера и в случае ошибки за- 
вершаем сеанс. 

22-23 Добавляем в конец ответа двоичный нуль и записываем строку на стан- 
дартный вывод. 


Запуск приложения через те! 


В отношении программы чарс11епе можно сделать два замечания: 


о в реализации клиента предполагается, что он всегда получит ответ от серве- 
ра. Как было сказано в совете 1, нет гарантии, что посланная сервером дата- 
грамма будет доставлена. Поскольку царс11епе - это интерактивная про- 
грамма, ее всегда можно прервать и запустить заново, если она «зависнет» 
в вызове гесуЕгом. Но если бы клиент не был интерактивным, нужно было 
бы взвести таймер, чтобы предотвратить потери датаграмм; 


Примечание В сервере иареспо1 об этом не нужно беспокоиться, так как 
точно известно, что датаграмма уже пришла (иначе 1пеЕане за- 
пустил бы сервер). Однако уже в следующем примере (листинг 3.6) 
приходится думать о потере датаграмм, так что таймер ас- 
социирован с гесуЁгом. 


о при работе с сервером иареспо1 не нужно получать адрес и порт отправите- 
ля, так как они уже известны. Поэтому строки 18 и 19 можно было бы заме- 
нить на: 


гс = гесуЕгош( $, БиЕЁ, $12еоЕЁ( БаЕЁ ) - 1, 0, М, М ); 


Но, как показано в следующем примере, иногда клиенту необходимо иметь 
информацию, с какого адреса сервер послал ответ, поэтому приведенные здесь 
ООР-клиенты всегда извлекают адрес. 

Для тестирования сервера добавьте в файл /еЕс/1пееа.сопЁ на машине Ъза 
строку 


уареспо азгам ч@р ма1®е )сз /изг/Вопе/3сз/иаресВо@а чаресвоа, 
ав файл /еёс/зегу1сез -— строку 
иаресро 8001 /пар 


Затем переименуйте цдресНо1 в паресНоа и заставьте программу 1пека пере- 
читать свой конфигурационный файл. При запуске клиента цдрс11епе на машине 
зрагкс получается: 


зрагс: $ чарс11епЕ Ьва чаресро 


опе 
28685: ове 
Фуо 

28686: Емо 
ЕЬгее 

28687: спгее 
АС 

зрагс: $ 


Этот результат демонстрирует важную особенность ОПР-серверов: они обыч- 
но не ведут диалог с клиентом. Иными словами, сервер получает один запрос 


УЖ — Создание эффективных сетевых программ 


и посылает один ответ. Для ЧОР-серверов, запускаемых через 1 пе" а, типичными 
будут следующие действия: получить запрос, отправить ответ, выйти. Выходить 
нужно как можно скорее, поскольку 1песа не будет ждать других запросов, на- 
правленных в порт этого сервера, пока тот не завершит сеанс. 

Из предыдущей распечатки видно, что, хотя складывается впечатление, будто 
ирс11епё ведет с паресВо1 диалог, в действительности каждый раз вызывается 
новый экземпляр сервера. Конечно, это неэффективно, но важнее то, что сервер не 
запоминает информации о состоянии диалога. Для идресво1 это несущественно, 
так как каждое сообщение - это, по сути, отдельная транзакция. Но так бывает не 
всегда. Один из способов решения этой проблемы таков: сервер принимает сооб- 
щение от клиента (чтобы избежать бесконечного цикла), затем соединяется с ним, 
получая тем самым новый (эфемерный) порт, создает новый процесс и завершает 
работу. Диалог с клиентом продолжает созданный вновь процесс. 


Примечание Есть и другие возможности. Например, сервер мог бы обслужи- 
вать нескольких клиентов. Принимая датаграммы от несколь- 
ких клиентов, сервер амортизирует накладные расходы на свой 
запуск и не завершает сеанс, пока не обнаружит, что долго про- 
стаивает без дела. Преимущество этого метода в некотором 
упрощении клиентов за счет усложнения сервера. 


Чтобы понять, как это работает, внесите в код иаресНо1 изменения, представ- 
ленные в листинге 3.6. 


Листинг 3.6. Вторая версия идреспоч 


паресво2.с 

1 #1пс]аае "ебср.В" 

2 1106 па1п( 116 агас, сВаг **агкау ) 

В 

4 зекгисЕ зоскаааг_1п реег; 

5 106 8; 

6 106 гс; 

7 106 1еп; 

8 116 р1а$2; 

9 саг БаЕЁ[ 120 ]; 

10 р14957 = зре1тЕЕЁ( БаЕ, "%А: ", дебр1а() ); 
11 1еп = $12еоЁ( реег )}; 
12 гс = гесуЕгом( 0, БаЕЁ + р1952, $12еоЁ( БаЕ ) - р1@в2, 
13 О, ( ЗзЕгасЕ зосКкааахг * )&реег, &1еп ); 

14 ТЕ (10) 
15 ех1е (1); 
16 3 = эзоскее( АЕ_ТМЕТ, $О0СК_ОСВАМ, 0}; 
17 ТЕ =. 0.) 

18 ех16 (1); 

19 1Е ( сорпесе( 5, ( зЕгасЕе зосКааахг * )&реег, 1еп ) < 0) 


20 ех1 (1); 


Запуск приложения через те ЧТ] | | |153. 


21 1Е ( ЕохгКк() != 0 } /* Ошибка или родительский процесс? */ 

22 ех1е (0); 

23 /* Порожденный процесс. */ 

24 ир1]е ( зекпспр( БаЁ + р1@52, "аопе", 4 }) != 0) 

25 { 

26 1Е ( икке( з, БЕ, гс + р19в7 ) <0) 

27 Ьгеак; 

28 р1Яв2 = зри1пЕЕ( БаЁ, "%4: ", дебр1а() ); 

29 а1аги( 30 }; 

30 гс = геаа( з, БаЕЁ + р1@а$7, з12еоЁ( БаЕЁ ) - р1937 ); 

31 а1аки( 0 )}; 

3:2 Е сео) 

33 ргеак; 

34 } 

35 ех1е (0 )}; 

36 } 

паресНо2.с 

иареспо2 

10-15 Получаем идентификатор процесса, записываем его в начало буфера 
и читаем первое сообщение так же, как в идресВо1. 

16-20 Получаем новый сокет и подсоединяем его к клиенту, пользуясь адре- 
сом в структуре реег, которая была заполнена при вызове кесуЁгом. 

21-22 Родительский процесс разветвляется и завершается. В этот момент 
1пеба может возобновить прослушивание хорошо известного порта 
сервера в ожидании новых сообщений. Важно отметить, что потомок 
использует номер порта пем, привязанный к сокету з в результате вы- 
зова соппесёЕ. 

24-35 Затем посылаем клиенту полученное от него сообщение, только с добав- 


ленным в начало идентификатором процесса. Продолжаем читать сооб- 
щения от клиента, добавлять к ним идентификатор процесса-потомка 
и отправлять их назад, пока не получим сообщение, начинающееся со 
строки допе. В этот момент сервер завершает работу. Вызовы а1аги, ок- 
ружающие операцию чтения на строке 30, -— это защита от клиента, ко- 
торый закончил сеанс, не послав допе. В противном случае сервер мог 
бы «зависнуть» навсегда. Поскольку установлен обработчик сигнала 
$ТСАЬВМ, ЧМХ завершает программу при срабатывании таймера. 


Переименовав новую версию исполняемой программы в чареспо4 и запустив 
ее, вы получили следующие результаты: 


зрагс: 


опве 


28743: 


мо 


28744: 


ЕЬтее 


$ чарс11епЕ Ъва чаресво 
оре 


Емо 


ТИ ИШЕ — Создание эффективных сетевых программ 


28744: сргее 
аопе 

^С 

зрагс: $ 


На этот раз, как видите, в первом сообщении пришел идентификатор родительс- 
кого процесса (сервера, запущенного 1пе{а), а в остальных - один и тот же иденти- 
фикатор (потомка). Теперь вы понимаете, почему и@рс11еп® всякий раз извлекает 
адрес сервера: ему нужно знать новый номер порта (а возможно, и новый [Р-адрес, 
если сервер работает на машине с несколькими сетевыми интерфейсами), в кото- 
рый посылать следующее сообщение. Разумеется, это необходимо делать только для 
первого вызова гесуЁхгощ, но для упрощения здесь не выделяется особый случай. 


Резюме 


В этом разделе показано, как заставить приложение работать в сети, прило- 
жив совсем немного усилий. Демон 1песа берет на себя ожидание соединений или 
датаграмм, дублирует дескриптор сокета на зЕЯ1п, зЕаоче и зе аегг и запускает 
приложение. После этого приложение может просто читать из Е а1п или писать 
в зЕаоце либо зЕдехг, не имея информации о том, что оно работает в сети. Рас- 
смотрен пример простого фильтра, в котором вообще нет кода, имеющего отноше- 
ние к сети. Но этот фильтр тем не менее прекрасно работает в качестве сетевого 
сервиса, если запустить его через 1пе64. 

Здесь также приведен пример ООР-сервера, который способен вести продол- 
жительный диалог с клиентами. Для этого серверу пришлось получить новый со- 
кет и номер порта, а затем создать новый процесс и выйти. 


Совет 18. Подумайте о том, чтобы хорошо 
известный номер порта назначался вашему 
серверу с помощью {сртих 


Проектировщик сетевого сервера сталкивается с проблемой выбора номера 
для хорошо известного порта. Агентство по выделению имен и уникальных пара- 
метров протоколов щегпей ([пбегпеё Азз1;те4 Митьегз Ачфогцу - ТАМА) подраз- 
деляет все номера портов на три группы: «официальные» (хорошо известные), за- 
регистрированные и динамические, или частные. 


Примечание Термин «хорошо известный порт» используется в общем смыс- 
ле — как номер порта доступа к серверу. Строго говоря, хорошо 
известные порты контролируются агентством ГАМА. 


Хорошо известные - это номера портов в диапазоне от 0 до 1023. Они контро- 
лируются агентством ГАМА. Зарегистрированные номера портов находятся в диа- 
пазоне от 1024 до 49151. ТАМА не контролирует их, но регистрирует и публикует 
в качестве услуги сетевому сообществу. Динамические или частные порты имеют 
номера от 49152 до 65535. Предполагается, что эти порты будут использоваться 


Назначение номера порта с помощью 1‹ртих НВА 


как эфемерные, но многие системы не следуют этому соглашению. Так, системы, 
производные от В$О, традиционно выбирают номера эфемерных портов из диа- 
пазона от 1024—5000. Полный список всех присвоенных [АМА и зарегистриро- 


ванных номеров портов можно найти на сайте Вр: / ммм 151.е4и /п-побезЛапа/ 
аз ептере/рог(-питБегс/. 


Проектировщик сервера может получить от [АМА зарегистрированный номер 
порта. 


Примечание Чтобы подать заявку на получение хорошо известного или за- 
регистрированного номера порта, зайдите на Ие-страницу 


Вир /вишая.еди/ст-бтлапа/роп-питфегз.. 


Это, конечно, не помешает другим использовать тот же номер, и рано или позд- 
но два сервера, работающие с одним и тем же номером порта, окажутся на одной 
машине. Обычно эту проблему решают, выделяя некоторый номер порта по умол- 
чанию, но позволяя задать другой в командной строке. 

Другое более гибкое решение, но применяемое реже, состоит в том, чтобы ис- 
пользовать возможность 1пе а (совет 17), которая называется мультиплексором 
портов ТСР (ТСР Рок Зегусе Миирехог - ТСРМИХ). Сервис ТСРМИОХ опи- 
сан в КЕС 1078 [Го&ег 1988]. Мультиплексор прослушивает порт 1 в ожидании 
ТСР-соединений. Клиент соединяется с ТСРМОХ и посылает ему строку с име- 
нем сервиса, который он хочет запустить. Строка должна завершаться символа- 
ми возврата каретки и перевода строки (<СК><Г.Е>). Сервер или, возможно, 
ТСРМОХ посылает клиенту один символ: + (подтверждение) или - (отказ), за 
которым следует необязательное пояснительное сообщение, завершаемое после- 
довательностью <СК><ГЕ>. Имена сервисов (без учета регистра) также хранят- 
ся в файле 1пеЕ Я. сопЕ, но начинаются со строки Е сртих/, чтобы отличить их от 
обычных сервисов. Если имя сервиса начинаются со знака +, то подтверждение 
посылает ТСРМОХ, а не сервер. Это позволяет таким серверам, как г1 пита (лис- 
тинг 3.3), которые проектировались без учета ТСРМИХ, все же воспользоваться 
предоставляемым им сервисом. 

Например, если вы захотите запустить сервис подсчета строк из совета 17 в ка- 
честве ТСРМОХ-сервера, то надо добавить в файл 1пеЕ@.сопЕ строку 


Ссриах/+г1пищЯ зегеам &ср пома1® 3сз /азг/]още/)с®/х1пиаа х]попа 


Для тестирования заставьте 1песа перечитать свой конфигурационный файл, 
а затем подсоединитесь к нему с помощью еше, указав имя сервиса ТСРМОХ: 


рза: $ ве1пеЕ 1оса]1ВовЕ Есрпах 
Тгулиа 127;:0:0.:1 
СоппескеЯ ко 1оса1Нозе 
Езсаре спагасеег 1$ "^]". 
х1рааа 
+Со 
Бе11о 
1: Ве11о 
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мог1а 

2: мог1а 
^] 
се1пеё> аа1еЕ 
СоппесЕ1оп с1о5еа 
Ьза: $ 


К сожалению, сервис ТСРМОХ поддерживается не всеми операционными систе- 
мами и даже не всеми ОМХ-системами. Но, с другой стороны, его реализация настоль- 
ко проста, что возможно написать собственную версию. Поскольку ТСРМОХ должен 
делать почти то же, что и 1пе& (за исключением мониторинга нескольких сокетов) 
заодно будут проиллюстрированы те идеи, которые лежат в основе 1пеЕ а. Начнем 
с определения констант, глобальных переменных и функции па1п (листинг 3.7). 


Листинг 3.7. кртих - константы, глобальные переменные и тат 


Есртих.с 

1 пс1аае "еёср.В" 

2 #АеРлпе МАХАВС$ 10 /* Максимальное число аргументов сервера. */ 
3 #АеЕ1пе МАХЬТМЕ 256 /* Максимальная длина строки в бсриах.сопЕ. */ 
4 заеЕ1пе МУЕВУТАВ 10 /* Число элементов в таблице зегу1се_ба Пе. */ 
5 #аеЕ1пе СОМЕТС "с српих.сопЁ" 

6 СуреаеЕ зЕгасе 

а 

8 116 Е1аа; 

9 спаг *5егу\у1се; 
10 спаг *раёЁП; 
и сваг *агдаз[ МАХАКС$ + 1 ]; 
12 } зегубаь_2; 

13 106 18; /* Прослушиваемый сокет. */ 
14 зехубаБ_Е взегу1се_баБ1е[ МЗЕВУТАВ + 1 ]; 

15 106 па1п( 116 агас, сраг **агау )} 

16 { 

17 зекисЕ зоскаааг_1п реег; 

18 106 8; 

19 106 реег1еп; 
20 /* Инициализировать и запустить сервер бсримах. */ 
21 ТМТТ(); 
22 рагзебаЬ(); 
23 зи1Еср ( акас )} 

24 { 

25 савзе 1: /* Все по умолчанию. */ 

26 13 = Сср_вегуег( МО, "Есрпах" ); 

27 Ьгеак; 

28 сазе 2: /* Задан интерфейс и номер порта. */ 

29 13 = Еср_вегуег( агаду[ 1 |], "Есрмах" ); 


30 ЪтеаКк; 


Назначение номера порта с помощью #<ртих ] ЕТУ 


31 сазе 3; /* Заданы все параметры. */ 

32 15 = Еср_векуег( агаду[ 1 ], агкау[ 2] ); 

33 ргеак; 

34 ЯЧеЁац1 6: 

35 егког( 1, 0, "Вызов: %8 [ интерфейс [ порт ] ]\п'", 
36 ргкоакапм_паме }; 

37 } 


38 Заепоп( 0, 0); 
39 819па]1( ЭТССНЬО, геарек ); 


40 /* Принять соединения с портом Есриих. */ 
41 сы 
42 { 
43 реег1еп = $12е0оЁ( реег }; 
44 3 = ассере( 15, ( зЕкгисЕ зосКаааг * }&реег, &реег1епт ); 
45 1Е (в <0) 
46 сопЕ1пче; 
47 зсаге_вегуегк( з ); 
48 СТОЗЕ( в ); 
49 } 
50 } 
Еертих.с 
тат 


6-12 Структура зегусаЪ_Е определяет тип элементов в таблице 
зегу1се_6аЪ1е. Поле Ё1ад устанавливается в ТВОЕ, если подтверж- 
дение должен посылать Е сриих, а не сам сервер. 

22 В начале вызываем функцию рагзекаъ, которая читает и разбирает 
файл Есрших . сопЕ и строит таблицу зегу1се_ваЪ1е. Текст процеду- 
ры рагзекаЪ приведен в листинге 3.9. 

23-37 Данная версия Есрших позволяет пользователю задать интерфейс или 
порт, который будет прослушиваться. Этот код инициализирует сер- 
вер с учетом заданных параметров, а остальным присваивает значения 
по умолчанию. 


38 Вызываем функцию даетоп, чтобы перевести процесс Есрщих в фоно- 
вый режим и разорвать его связь с терминалом. 
39 Устанавливаем обработчик сигнала $тССНО. Это не дает запускаемым 


серверам превратиться в «зомби» (и зря расходовать системные ресур- 
сы) при завершении. 


Примечание В некоторых системах функция 519па1 — это интерфейс к сиг- 
налам со старой «ненадежной» семантикой. В этом случае надо 
пользоваться функцией э1дасЕзоп, которая обеспечивает се- 
мантику надежных сигналов. Обычно эту проблему решают пу- 
тем создания собственной функции 519па1, которая вызывает 
из себя э19асЕзол. Такая реализация приведена в приложении 1. 
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41-49 В этом цикле принимаются соединения с &сртих и вызывается функ- 
ЦИЯ зсаге_зегуег, которая создает новый процесс с помощью Еогк 
и запускает запрошенный сервер с помощью ехес. 


Теперь надо познакомимся с функцией зЕаг+_зегуех (листинг 3.8). Именно 
здесь выполняются основные действия. 


Листинг 3.8. Функция з{апП.зегиег 


Еесртих.с 
1 эеаЕё1с \уо1Я збаге_вехгуех( 116 $ } 
24 
3 спаг 11пе[ МАХЦТМЕ )}; 
4 зегубаь_е *з6р; 
5 тие те: 
6 збаё1с сНаг ехх1[] = "-не могу прочесть имя сервиса \г\п"; 
г. зсаё1с сраг егг2[] = "-неизвестный сервис\х\п"; 
8 збабё1с спахг егх3[] = "-не могу запустить сервис\г\п"; 
9 з6ае1с спахг окК[] = "+О0К\х\п"; 
10 гс = ЕокК(); 
11 ТЕ ео) /* Ошибка вызова ЕотК. */ 
фа { 
13 мг1Ее( $, ехгхгЗ, в12еоЁ( еггЗз ) - 1); 
14 гебати; 
ть } 
16 Еве 1 07) /* Родитель. */ 
17 гебагп; 
18 /* Процесс-потомок. */ 
19 СЬО$Е( 18 ); /* Закрыть прослушивающий сокет. */ 


20 а1агм( 10 ); 

21 ГС = геаЯсг1Е( в, 110е, в12еоЕЁ( ]11пе ) ); 
22 а1агщ( 0 ); 

23 1Е (кс <= 0) 


24 { 

р уг16е( 3, егх1, з1хеоЁ( егг1 ) - 1); 

26 ЕХ!Т 1); 

27 } 

28 Гог ( з6р = зеку1се_бар1е; зЕр->вегу1се; в6р++ ) 
29 1Е ( зЕгсазестр( 11ре, зЕр->зеху1се ) == 0) 
30 ргеак; 

Зи 1Е ( !зЕр->зегузсе ) 

32 { 

33 уг1ее( 3, егкг2, з12е0Ё( егг2 ) - 1}; 

34 ЕХТТ (1); 

35 } 


36 1Е ( зЕр->Е1ача ) 
37 РЕ ме 5. ОЕ. за 26 о) 0 


Назначение номера порта с помощью кртих {010 ЗАВЕТ: 


38 ХЕ, 4 

39 Яар2 (в, 0); 

40 аира, 1): 

41 Чцр2 (зв, 2); 

42 СЬОЗЕ (3 ); 

43 ехесу( зЕер->раёП, зёр->агаз ); 

44 иг16е( 1, егг3З, з12ео0оЁ( егхз ) - 1); 

45 ХТ 1: 

46 } 

Есртих.с 

УагЕ егуег 

10-17 Сначала с помощью системного вызова ЕогК создаем новый процесс, 
идентичный своему родителю. Если ЕохК завершился неудачно, то по- 
сылаем клиенту сообщение об ошибке и возвращаемся (раз ЕохК не от- 
работал, то процесса-потомка нет, и управление возвращается в функ- 
цию па1п родительского процесса). Если ЕохК завершился нормально, 
то это родительский процесс, и управление возвращается. 

19-27 В созданном процессе закрываем прослушивающий сокет и из подсо- 
единенного сокета читаем имя сервиса, которому нужно запустить 
клиент. Окружаем операцию чтения вызовами а1агт, чтобы завер- 
шить работу, если клиент так и не пришлет имя сервиса. Если функ- 
ЦИЯ геа@сг1 Е возвращает ошибку, посылаем клиенту сообщение и за- 
канчиваем сеанс. Текст геадсг1Е приведен ниже в листинге 3.10. 

28-35 Ищем в таблице зегу1се_саЪ1е имя запрошенного сервиса. Если оно 
отсутствует, то посылаем клиенту сообщение об ошибке и завершаем 
работу. 

36-38 Если имя сервиса начинается со знака +, посылаем клиенту подтверж- 
дение. В противном случае даем возможность сделать это серверу. 

39-45 С помощью системного вызова дир дублируем дескриптор сокета на Е 911, 


зЕЧочЕ и зЕаекк, после чего закрываем исходный сокет. И, наконец, 
подменяем процесс процессом сервера с помощью вызова ехесу. После 
этого запрошенный клиентом сервер - это процесс-потомок. Если ехесу 
возвращает управление, то сообщаем клиенту, что не смогли запустить 
запрошенный сервер, и завершаем сеанс. 


В листинге 3.9 приведен текст подпрограммы рагзекаьЪ. Она выполняет про- 
стой, но несколько утомительный разбор файла Е српих . сопЕ. Файл имеет следу- 
ющий формат: 


имя_сервиса путь аргументы 


Листинг 3.9. Функция рагзейаь 


ияиюфьювю 


Есртих.с 


зЕае1с \уо1@ рагзекаь( хуо1а } 
{ 


ЕТЬЕ *Ер; 
зекубар_® *з6р = зеку1се_ваЬ1е; 
срах *ср; 
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6 116 1; 
7 116 11пепо; 
8 сПахг 11пе[ МАХЬТМЕ |]; 


9 Ер = Еореп( СОМЕТС, "г" ); 
10 1Е ( Ер == Ш  ) 


11 еггохг( 1, еггпо, "не могу открыть %8", СОМЕТС ); 

12 11пепо = 0; 

13 У\111е ( ЕдеЕз( 11пе, з12еоЁ( 11пе ), Ер) != № ) 

14 { 

15 11пепо++; 

16 1Е ( 11пе[ з6г1еп( 11е } - 1] != '\п'’) 

р еггох( 1, 0, "строка %Я слишком длинная\п", 11пепо ); 
18 1Е ( зЕр >= вегу1се_ваБ1е + М$ЗЕВУТАВ ) 

19 еггохг( 1, 0, "слишком много строк в Есрмих.сопЕ\п" ); 
20 ср = зЕгсрк( 11пе, '#' ); 

21 1Е (ср != МЫ )} 

22 а А 

23 ср = збубок( 11пе, " \Е\п" ); 

24 1Е (ср == Ш ) 

25 сопЕ1пие; 

26 1Е ( *ср == '+' ) 

27 { 

28 зЕр->Ё1аа = ТВОЕ; 

29 ср++: 

30 Е сер == "01| вбуенес" Аи зору 1= м9БЬ 
31 еггог( 1, 0, "строка $4: пробел после '+’\п", 
32 11пепо ); 

33 } 

34 зЕр->зеху1се = зёгаор( ср ); 

35 1ЁЕ ( зЕр->вегу1се == МШ. ) 

36 еггохг( 1, 0, "не хватило памяти\п" }; 

37 ср = збубок( МОБЬ, " \6\п" ); 

38 1Е ( ср == Ш ) 

39 еггох( 1, 0, "строка %&: не задан путь (%$)\п", 
40 11пепо, зЕр->зегу1се ); 

41 $Ер->раЁЙ = эёгачр( ср }); 

42 1Е ( зер-ьрабв == м } 

43 еггохг( 1, 0, "не хватило памяти\п”“ ); 

44 Еог (1 = 0: 1 < МАХАВС$; 1++ ) 

45 { 

46 ср = зЕубок( МОБЬ, " \6\ш" ); 

47 ТЕ ( ср == МЫ. ) 

48 ргеак; 

49 зЕр->агаз[ 1 ] = зЕхгаар( ср ); 

50 1Е ( зЕёр->агаз( 1 ] == мМШ ) 

51 еггохг( 1, 0, "не хватило памяти\п" ); 

52 } 

53 1Е (1 >= МАХАВС$ && эзегбок( МОШЬ, " \Е\п" ) != м ) 


54 еггог( 1, 0, "строка %&: слишком много аргументов ($5)\п", 


Назначение номера порта ‹ помощью 1сртих 0 О М ЕЯ] 


55 ]1пепо, зёр->зегу1се ); 
56 зёр->агаз[ 1 ] = М; 

57 $6р++; 

58 } 


59 з6р->5егу1се = М; 
60 Ес1о5е ( Ёр )}; 
6. 
Есртих.с 


Показанная в листинге 3.10 функция геааск1Ё читает из сокета по одному 
байту. Хотя это и неэффективно, но гарантирует, что будет прочитана только пер- 
вая строка данных, полученных от клиента. Все данные, кроме первой строки, 
предназначены серверу. Если бы вы буферизовали ввод, а клиент послал бы боль- 
ше одной строки, то часть данных, адресованных серверу, считывал бы Есриих, 
и они были бы потеряны. 

Обратите внимание, что геайск1{ принимает также и строку, завершающую- 
ся только символом новой строки. Это находится в полном соответствии с прин- 
ципом устойчивости [Розе] 1981а], который гласит: «Подходите не слишком стро- 
го к тому, что принимаете, но очень строго — к тому, что посылаете». В любом 
случае как <СВ><Г.Е>, так и одиночный <Г.Е> отбрасываются. 

Определение функции геааск1{ такое же, как функций геа@, хеаЯ11пе, 
теа@п и геадугес: 


#10с1аае "ебср.В" 
106 геаЯсу1Ё( СОСКЕТ 5, сраг *РБиЕЁ, з1а2е_Е 1еп }; 


Возвращаемое значение: число прочитанных байт или —1 в случае ошибки. 


Листинг 3. 10. Функция геадс!! 


геаасх1Е.с 
106 геа@сг1ЁЕ( ЗОСКЕТ $, срак *раЕЁ, в12е_6 ]еп ) 


1 

2 

3 сах *БаЁх = БаЕЁ; 
4 106 гс; 

5 сраг с; 

6 спаг 1азбс 
7 

8 


0; 
%01]е ( 1еп > 0) 


9 ТЕ ( (с = гесу( в, &с, 1,0) ) !=1) 
10 { 

11 /* 

12 * Если нас прервали, повторим, 

13 * иначе вернем ЕОЕ или код ошибки. 
14 ыы 

15 1Е (тс < 0 && еггро == ЕТМТВ ) 


16 сопЕ1тме; 


[162 1 РТВ 


17 
18 
19 
20 
21 
22 
23 
24 
25 


26 
27 
28 
ро 
30 
ЗЕ 
32 


} 


кебсицгп гс; 


1Е (с == '\п' 
{ 
1Е ( 1азбсс 
РаЕ--; 
*БоаЕ = 


'\0:; 


Е 5] 


/* 


хгебсиги БаЕ - БаЁх; 


} 


*5Ё++ = 
1азес = 
1еп--; 

} 

зеё_еккпо ( 

хгебахги -1; 


ЕМ5ССТОЕ 


}# 


Не включать <СВ><ЬЕ>. 
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ый. 


геаасг1Е.с 


И наконец рассмотрим функцию геарег (листинг 3.11). Когда сервер, запу- 
щенный с помощью Е сртих, завершает сеанс, ОМГХ посылает родителю (то есть 
Есрмих) сигнал $тссньо. При этом вызывается обработчик сигнала геарек, ко- 
торый, в свою очередь, вызывает ма1Ер1а для получения статуса любого из за- 
вершивигихся потомков. В системе ОМХ это необходимо, поскольку процесс-по- 
томок может возвращать родителю свой статус завершения (например, аргумент 
функции ех16). 


Примечание 


Внекоторых вариантах ОМХ потомок возвращает и другую ин- 


формацию. Так, в системах, производных от В5О, возвращается 
сводная информация о количестве ресурсов, потребленных завер- 
шившимся процессом и всеми его потомками. Во всех системах 
ОМХ, по меньшей мере, возвращается указание на то, как завер- 
шился процесс: из-за вызова ех1Е (передается также код возвра- 
та) или из-за прерывания сигналом (указывается номер сигнала). 


Пока родительский процесс не заберет информацию о завершении потомка 
с помощью вызова ма1& или ма1ер19, система ОХ должна удерживать ту часть 
ресурсов, занятых процессом-потомком, в которой хранится информация о состо- 
янии. Потомки, которые уже завершились, но еще не передали родителю инфор- 
мацию о состоянии, называются мертвыми (Че псе) или «зомби». 


Листинг 3.11. Функция геарег 


ль шв 


У01Я геарег ( 


{ 


10е мазезсаецс; 


\п11е ( мазЕр1а ( 


1пЕ в1а ) 


№ 


&мазе бабе, 


УМОНАМС ) 


>20) 


Есртих.с 


{;} 


Есртих.с 
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Протестируйте Е сриих, создав файл Есрмих . сопЁ из одной строки: 
+г1пам /азг/ропе/3сз/хг1пама г1рама 


Затем запустите Есртих на машине зрагс, которая не поддерживает сервиса 
ТСРМОХ, и соединитесь с ним, запустив (епеё на машине за. 


зрагс: # всртах 


Ьза: $ &е1пеЕ врагс Есрпах 
Тку1па 127.0.0.1 
СоппесёеЯ во зрагс 
Езсаре спагасфег 13$ '^]'. 
х1пипа 
+ОК 
Ве11о 

1: Ве1]о 
мог1а 

2: могла 
^] 
се1пее> аи1 
Соппесе1оп с1озеа 
Ьза: $ 


Резюме 


Сервис ТСРМИХ, имеющийся на очень многих системах, помогает решить 
проблему выбора хороуо известного номера порта сервера. Здесь реализована соб- 
ственная версия демона Е сртих, так что если в какой-то системе его нет, то им мож- 
но воспользоваться. 


Совет 19. Подумайте об использовании 
двух ТСР-соединений 


Во многих приложениях удобно разрешить нескольким процессам или пото- 
кам читать из ТСР-соединений и писать в них. Особенно распространена эта прак- 
тика в системе ОМХ, где по традиции создается процесс-потомок, который, на- 
пример, пишет в ТТУ-соединение, тогда как родитель занимается чтением. 

Типичная ситуация изображена на рис. 3.3, где показан эмулятор терминала. 
Родительский процесс большую часть времени блокирован в ожидании ввода из 
ТТУ-соединения. Когда на вход поступают данные, родитель читает их и выво- 
дит на экран, возможно, изменяя на ходу формат. Процесс-потомок в основном 
блокирован, ожидая ввода с клавиатуры. Когда пользователь вводит данные, 
потомок выполняет необходимые преобразования и записывает данные в ТТУ- 
соединение. 

Эта стратегия удобна, поскольку позволяет автоматически мультиплексиро- 
вать ввод с клавиатуры и из ТТУ-соединения и разнести логику преобразования 
кодов клавиш и форматирования вывода на экран по разным модулям. За счет это- 
го программа получается концептуально проще, чем в случае нахождения кода 
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Родитель 
(читатель) 
Потомок 
(писатель) 


Рис. 3.3. Два процесса, обслуживающие ТТУ-соединение 


Экран 


соединение 


Клавиатура 


в одном месте. В действительности, до появления в операционной системе меха- 
низма зе1ес® это был единственный способ обработки поступления данных из 
нескольких источников. 


Архитектура с одним соединением 


Следует заметить, что ничего не изменится, если на рис. 3.3 вместо ТТУ-со- 
единения будет написано ТСР-соединение. Поэтому та же техника может приме- 
няться (и часто применяется) для работы с сетевыми соединениями. Кроме того, 
использование потоков вместо процессов почти не сказывается на ситуации, изоб- 
раженной на рисунке, поэтому этот метод пригоден и для многопоточной среды. 

Правда, есть одна трудность. Если речь идет о ТТУ-соединении, то ошибки при 
операции записи возвращаются самим вызовом ит 1‹е, тогда как в случае ТСР ошиб- 
ка, скорее всего, будет возвращена последующей операцией чтения (совет 15). 
В многопроцессной архитектуре процессу-читателю трудно уведомить процесс- 
писатель об ошибке. В частности, если приложение на другом конце завершается, 
то об этом узнает читатель, который должен как-то известить писателя. 

Немного изменим точку зрения и представим себе приложение, которое при- 
нимает сообщения от внешней системы и посылает их назад по ТСР-соединению. 
Сообщения передаются и принимаются асинхронно, то есть не для каждого вход- 
ного сообщения генерируется ответ, и не каждое выходное сообщение посылается 
в ответ на входное. Допустим также, что сообщения нужно переформатировать на 


пр 
(обработчик Внешняя 


сообщений) соединение система 


Рис. 3.4. Приложение, обменивающееся сообщениями по ТСР-соединению 
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входе или выходе из приложения. Тогда представленная на рис. 3.4 архитектура 
многопроцессного приложения оказывается вполне разумной. 

На этом рисунке процесс х1п читает данные от внешней системы, накапливает 
их в очереди сообщений, переформатирует и передает главному процессу обработ- 
ки сообщений. Аналогично процесс хоче приводит выходное сообщение к фор- 
мату, требуемому внешней системой, и записывает данные в ТСР-соединение. Глав- 
ный процесс пр обрабатывает отформатированные входные сообщения и генерирует 
выходные сообщения. Оставляем неспецифицированным механизм межпроцесс- 
ного взаимодействия (ТРС) между тремя процессами. Это может быть конвейер, 
разделяемая память, очереди сообщений или еще что-то. Подробнее все возмож- 
ности рассмотрены в книге [5еуепз 1999]. В качестве реального примера такого 
рода приложения можно было бы привести шлюз, через который передаются со- 
общения между системами. Причем одна из систем работает по протоколу ТСР, 
а другая — по какому-либо иному протоколу. 

Если обобщить этот пример, учитывая дополнительные внешние системы 
с иными требованиями к формату сообщений, то становится ясно, насколько гиб- 
кие возможности предоставляет описанный метод. Для каждого внешнего хоста 
имеется свой набор коммуникационных процессов, работающих только с его со- 
общениями. Такая система концептуально проста, позволяет вносить изменения, 
относящиеся к одному из внешних хостов, не затрагивая других, и легко конфи- 
гурируется для заданного набора внешних хостов — достаточно лишь запустить 
свои коммуникационные одеееы для каждого хоста. 

Однако при этом остается нерешенной вышеупомянутая проблема: процесс- 
писатель не может получить сообщение об ошибке после операции записи. А иног- 
да у приложения должна быть точная информация о том, что внешняя система 
действительно получила сообщение, и необходимо организовать протокол под- 
тверждений по типу того, что обсуждался в совете 9. Это означает, что нужно либо 
создать отдельный коммуникационный канал между процессами х1п и хоче, либо 
х1п должен посылать информацию об успешном получении и об ошибках про- 
цессу пр, который, в свою очередь, переправляет их процессу хоче. То и другое 
усложняет взаимодействие процессов. 

Можно, конечно, отказаться от многопроцессной архитектуры и оставить все- 
го один процесс, добавив зе1есе для мультиплексирования сообщений. Однако 
при этом приходится жертвовать гибкостью и концептуальной простотой. 

Далее в этом разделе рассмотрим альтернативную архитектуру, при которой 
сохраняется гибкость, свойственная схеме на рис. 3.4, но каждый процесс самосто- 
ятельно следит за своим ТСР-соединением. 


Архитектура с двумя соединениями 


Процессы х1п и хоче на рис. 3.4 делят между собой единственное соединение 
с внешней системой, но возникают трудности при организации разделения ин- 
формации о состоянии этого соединения. Кроме того, с точки зрения каждого из 
процессов х1п и хоче, эТо соединение симплексное, то есть данные передаются по 
нему только в одном направлении. Если бы это было не так, то хоцЕ «похищал» 
бы входные данные у х1п, а х1п мог бы исказить данные, посылаемые хоце. 
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Решение состоит в том, чтобы завести два соединения с внешней системой — 
по одному для х1п и хоце. Полученная после такого изменения архитектура изоб- 
ражена на рис. 3.5. 


Входное 
соединение 


пр 
(обработчик 


Внешняя 


сообщений) система 


Выходное 
соединение 


Рис. 3.5. Приложение, обменивающееся сообщениями по двум ТСР-соединениям 


Если система не требует отправки подтверждений на прикладном уровне, 
то при такой архитектуре выигрывает процесс хоч, который теперь имеет воз- 
можность самостоятельно узнавать об ошибках и признаке конца файла, послан- 
ных партнером. С другой стороны, хоче становится немного сложнее, поскольку 
для получения уведомления об этих событиях он должен выполнять операцию чте- 
ния, К счастью, это легко можно обойти с помощью вызова зе1есе. 

Чтобы это проверить, запрограммируем простой процесс хоче, который читает 
данные из стандартного ввода и записывает их в ТСР-соединение. Программа, по- 
казанная в листинге 3.12, с помощью вызова зе1есе ожидает поступления данных 
из соединения, хотя реально может прийти только ЕОЕ или извещение об ошибке. 


Листинг 3.12. Программа, готовая к чтению признака конца файла или ошибки 


хочЕТ. С 


1 #1пс1таае "ебср.В" 


2 116 па1о( 106 акас, сВаг **агау )} 


Еа_зее а11геааз; 
Га_зее геа@тазКк; 
ЗОСКЕТ $3; 

106 гс; 

сВаг БаЕЁ[ 128 |]; 


ТМТТ(); 
$ = Сср_с11епе( агау[ 1 ], агау[Г 2] ); 
ЕР _РЕКО( &а1]геаа$ ); 
ЕО_СЕТ( $, &а1]геа@а$ }; 
ЕО_СЕТ( 0, &а1]геааз )}; 
ОЕ р 
{ 
геаатазК = а11геа@з; 
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17 ГС = ве1есе( з + 1, &геаатазвк, МЬЬ, МЫ, МО ); 
18 1Е (кс <= 0) 
19 еггохг( 1, гс ? еггпо : 0, "зе1есЕ вернул %&", гс }; 
20 1Е ( ЕО Т55ЕТ( 0, &геаатазк ) ) 
21 { 
22 гс = геаЯ( 0, БаЕЁ, э12еоЁ( БоаЕЁ }) - 1); 
23 1Е (тс < 0) 
24 еггог( 1, еггпо, "ошибка вызова геа@" ); 
25 1Е ( зепа( з, БЕ, гс, 0) < 0) 
26 еггог( 1, еггпо, "ошибка вызова зепа" ); 
27 } 
28 1Е ( ЕБ Т55ЗЕТ( 5, &геа@тазКк ) ) 
29 { 
30 гс = гесу( $5, БаЕЁ, эза1хеоЕ( раЕЁ } - 1,0}; 
31 1Е (с == 0) 
32 еггохг( 1, 0, "сервер отсоединился\п" )}; 
33 е1зе 1Ё (тс < 0) 
34 еггог( 1, ехггпо, "ошибка вызова гесу" ); 
35 е1зе 
36 { 
37 БаЕ[ тс ] = '\0'; 
38 еггог( 1, 0, "неожиданный вход [%$]\п", БаЕЁ ); 
39 } 
40 } 
41 } 
42 } 
хоцЕТ.С 
Инициализация 


9-13 — Выполняем обычную инициализацию, вызываем функцию Еср_с11епе 
для установки соединения и готовим зе1ес® для извещения о наличии 
входных данных в стандартном вводе или в только что установленном 
ТСР-соединении. 


Обработка событий $4т 
20-27 Если данные пришли из стандартного ввода, посылаем их удаленному 
хосту через ТСР-соединение. 


Обработка событий сокета 

25-40 Если пришло извещение о наличии доступных для чтения данных в со- 
кете, то проверяем, это ЕОЕ или ошибка. Никаких данных по этому 
соединению не должно быть получено, поэтому если пришло что-то 
иное, то печатаем диагностическое сообщение и завершаем работу. 


Продемонстрировать работу хоцЕ1 можно, воспользовавшись программой Кеер 
(листинг 2.30) в качестве внешней системы и простым сценарием на языке интер- 
претатора команд зВе| для обработки сообщений (пр на рис. 3.5). Этот сценарий 
каждую секунду выводит На зЕЗоцЕ слово меззаде и счетчик. 


МУСМО=1 
ур11е Етце 
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ао 
еспо шеззаае $М$СМО 
31еер 1 
М5СМО="ехрк $М$СМО + 1" 
Чопе 


Обратите внимание, что в этом случае хоцЕ1 использует конвейер в качестве 
механизма [РС. Поэтому в таком виде программа хоцЕ1 не переносится на плат- 
форму УЯп4о\з, поскольку вызов зе1есЕ работает под \/!п40\з только для соке- 
тов. Можно было бы реализовать взаимодействие между процессами с помощью 
ТСР или ОПР, но тогда потребовался бы более сложный обработчик сообщений. 

Для тестирования хочЕ 1 запустим сначала «внешнюю систему» в одном окне, 
а обработчик сообщений и хочЕ1 - в другом. 


Ьза: $ Кеер 9000 Ьза: $ шр | хоцЕ1 1оса1Вове 9000 
пеззаде 1 
пеззаае 2 
пеззаае 3 
пеззааце 4 


^С "Внешняя система" хоцё1: сервер отсоединился 
завершила работу Вгокеп р1ре 
Ьза: $ Ьза: $ 


Сообщение ВхоКеп р1ре напечатал сценарий пр. При завершении программы 
хоцЕ1 конвейер между ней и сценарием закрывается. Когда сценарий пытается за- 
писать в него следующую строку, происходит ошибка, и сценарий завершается 
с сообщением Вгокеп р1ре. 

Более интересна ситуация, когда между внешней системой и приложением, 
обрабатывающим сообщения, необходим обмен подтверждениями. В этом случае 
придется изменить и х1п, и хоцЕ (предполагая, что подтверждения нужны в обоих 
направлениях; если нужно только подтверждать внешней системе прием сообще- 
ний, то изменения надо внести лишь в х1п). Разработаем пример только процесса- 
писателя (хоче). Изменения в х1п аналогичны. 

Новый процесс-писатель обязан решать те же проблемы, с которыми вы стол- 
кнулись при обсуждении пульсаций в совете 10. После отправки сообщения уда- 
ленный хост должен прислать нам подтверждение до того, как сработает таймер. 
Если истекает тайм-аут, необходима какая-то процедура восстановления после 
ошибки. В примере работа просто завершается. 

При разработке нового «писателя» хочЕ2 вы не будете принимать сообщений 
из стандартного ввода, пока не получите подтверждения от внешней системы о том, 
что ей доставлено последнее ваше сообщение. Возможен и более изощренный под- 
ход с использованием механизма тайм-аутов, описанного в совете 20. Далее он бу- 
дет рассмотрен, но для многих систем вполне достаточно той простой схемы, ко- 
торую будет применена. Текст хоцЕ2 приведен в листинге 3.13. 


Листинг 3. 13. Программа, обрабатывающая подтверждения 


хоицЕа. Сс 
1 #1пс1аае "ебср.!" 


2 #АеЕ1пе АСК 0х6/* Символ подтверждения АСК. */ 
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т 
{ 


пе мал ( 


Еа_зе в 
Еа_веё 
Еа_веё 
ЗЕХГИСЕ 
ЗЕКИСЕ 
ЗОСКЕТ 
106 гс 


106 агас, спаг **агау } 


а11геа@з; 

геаапазКк; 

зоскоп1у; 

Е1меуа]1 %\у; 

Е1щеуа *Еур = М; 
8; 


. 
: 


сраг БаЕ[ 128 }; 
сопзЕ збае1с зекгисе Е1теуа1 ТО = {2,0}; 


ТМТТ() 


. 
: 


3 = Еср_с11епе( агау[ 1 ], акау[ 2 ] ); 
ЕР_2ЕКО( &а11хгеааз ); 


ЕР _СЕТ( 3, &а1!1геааз ); 
зосКкоп]1у = а11геа@з; 
ЕО _СЕТ( 0, &а1!1геааз )}; 
геа@мазкК = а11геааз; 
РО 
{ 
гс = зе]1есе( в + 1, &геа@тазк, МОБЬ, МЫ, ЕУр ); 
Ее а = 0) 
егхгог( 1, еггпо, "ошибка вызова зе1есе" ); 
1Е (кс == 0) 
еггог( 1, 0, "тайм-аут при приеме сообщения\п" }; 
1Е ( ЕО _Т55ЕТ( зв, &геа@амазк } } 
{ 
гс = гесу( з, БаЕЁ, з1хеоЁ( БаЕЁ }, 0}; 
1Е (хс == 0) 
еггог( 1, 0, "сервер отсоединился\п" )}; 
е1зе 1Е (гс < 0) 
егхгог( 1, егхгпо, "ошибка вызова гесу" }; 
е]1зе 1Ё (тс != 1 || БЕГ 0 }] != АСК ) 


еггог( 1, 0, "неожиданный вход [%°с]\п", БЕГ О] }; 
сур = МОЬЬ; /* Отключить таймер */ 
геадтазКк = а11]геа@Яз; /* и продолжить чтение из 6911. */ 


} 
1Е ( ЕО _Т$5ОЕТ( 0, &геаатазк )} ) 
{ 
гс = геаЯ( 0, БЕ, в12еоЁ( БаЕЁ ) }; 
1Е (тс < 0) 
еггог( 1, еггпо, "ошибка вызова геа@" }; 
1Е ( зсера( з, ВЕ, гс, 0) <0) 
еггог( 1, еггпо, "ошибка вызова зепа" }; 
6у = ТО; /* Переустановить таймер. */ 
сур = &6%; /* Взвести таймер */ 
геаЯатазК = зоскКоп1у; /* и прекратить чтение из зЕ91п. */ 
} 
} 


—хоцЕ2. С 
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Инициализация 

14-15 Стандартная инициализация ТСР-клиента. 

16-20 Готовим две маски для зе1ескЕ: одну для приема событий из 3191п 
и ТСР-сокета, другую для приема только событий из сокета. Вторая 
маска зоскоп1у применяется после отправки данных, чтобы не читать 
новые данные из $11, пока не придет подтверждение. 


Обработка событий таймера 


26-27 Если при вызове зе1ес® произошел тайм-аут (не получено вовремя под- 
тверждение), то печатаем диагностическое сообщение и завершаем сеанс, 


Обработка событий сокета 

28-39 Если пришло извещение о наличии доступных для чтения данных 
в сокете, проверяем, это ЕОЕ или ошибка. Если да, то завершаем рабо- 
ту так же, как в листинге 3.12. Если получены данные, убеждаемся, что 
это всего один символ АСК. Тогда последнее сообщение подтвержде- 
но, поэтому сбрасываем таймер, устанавливая переменную Е Ур в МОБ, 
и разрешаем чтение из стандартного ввода, устанавливая маску геадтазк 
так, чтобы проверялись и сокет, и ЗЕ Я1 п. 


Обработка событий в ат 

40-66 Получив событие зЕ Я 11, проверяем, не признакли это конца файла. Если 
чтение завершилось успешно, записываем данные в ТСР-соединение. 

47-50 Поскольку данные только что переданы внешней системе, ожидается 
подтверждение. Взводим таймер, устанавливая поля структуры Е \ 
и направляя на нее указатель сур. В конце запрещаем события зЕЯ1п, 
записывая в переменную геа@атазК маску зосКоп1у. 


Для тестирования программы хочЕ2 следует добавить две строки 


1Е ( вела( з1, "\006", 1, 0) < 0) /* \006 == АСК */ 
еггог( 1, еггпо, "ошибка вызова зепа" }; 


перед записью на строке 24 в исходном тексте Кеер.с (листинг 2.30). Если выпол- 
НИТЬ Те же действия, как и для программы хоч 1, то получим тот же результат с тем 
отличием, что хоцЕ2 завершает сеанс, не получив подтверждения от удаленного хоста. 


Резюме 


В этом разделе обсуждалась идея об использовании двух соединений между 
приложениями. Это позволяет отслеживать состояние соединения даже тогда, 
когда чтение и запись производятся в разных процессах. 


Совет 20. Подумайте, не сделать ли приложение 
событийно-управляемым (1) 


В этом и следующем разделах будет рассказано об использовании техники со- 
бытийной управляемости в программировании ТСР/Р. Будет разработан универ- 
сальный механизм тайм-аутов, позволяющий указать программе, что некоторое 
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событие должно произойти до истечения определенного времени, и асинхронно 
приступить к обработке этого события в указанное время. Здесь рассмотрим реа- 
лизацию механизма таймеров, а в совете 21 вернемся к архитектуре с двумя соеди- 
нениями и применим его на практике. 

Разница между событийно-управляемым и обычным приложением хорошо 
иллюстрируется двумя написанными ранее программами: Н5_с11епЕ2 (листинги 
2.2би 2.27) и Есрги (листинг 2.21). В Есрги поток управления последовательный: 
сначала из стандартного ввода читается строка и передается удаленному хосту, 
а затем от него принимается ответ и записывается на стандартный вывод. Обрати- 
те внимание, что нет возможности ничего принять от удаленного хоста, пока ожи- 
дается ввод из зе Я1п. Как вы видели, в результате можно не знать, что партнер за- 
вершил сеанс и послал ЕОЕ Ожидая также ответа от удаленного хоста, вы не 
можете читать новые данные из зЕ91п. Это значит, что приложение, с точки зре- 
ния пользователя, слишком медленно реагирует. Кроме того, оно может «завис- 
нуть», если удаленный хост «падает» до того, как приложение ответило. 

Сравните это поведение с работой клиента ВЪ_с11епё2, который в любой 
момент способен принимать данные по любому соединению или завершиться 
по тайм-ауту. Ни одно из этих событий не зависит от другого, именно поэтому 
такая архитектура называется событийно-управляемой. 

Заметим, что клиента ВЪ_с11епе2 можно легко обобщить на большее число 
соединений или источников входной информации. Для этого существует механизм 
зе1ес®, который позволяет блокировать процесс в ожидании сразу нескольких со- 
бытий и возвращатьему управление, как только произойдет любое из них. В системе 
ОМХ этот механизм, а также родственный ему вызов ро11, имеющийся в системах 
на базе 5уз\У, — это единственный эффективный способ обработки асинхронных со- 
бытий в немногопоточной среде. 


Примечание До недавнего времени считалось, что из соображений переноси- 
мости следует использовать ве1есь, а не ро11, так как на плат- 
форме Утао5, а равно в современных ИМХ-системах поддер- 
живается именно ве1есЕ, тогда как ро11 встречается обычно 
в реализациях на базе Зу5У. Однако некоторые большие серверные 
приложения (например, МеБ-серверы), поддерживающие очень 
много одновременных соединений, применяют механизм ро]11, 
так как он лучше масштабируется на большое число дескрипто- 
ров. Дело в том, что зе1есЕ ограничен фиксированным числом 
дескрипторов. Обычно их не больше 1024, но бывает и меньше. 
Так, в системе ЕгееВЗР и производных от нее по умолчанию пре- 
дел равен 256. Для изменения значения по умолчанию нужно пере- 
собирать ядро, что неудобно, хотя и возможно. Но и пересборка 
ядра лишь увеличивает предел, а не снимает его. Механизм же 
ро11 не имеет встроенных ограничений на число дескрипторов. 
Следует также принимать во внимание эффективность. Ти- 
пичная реализация зе1есЕ может быть очень неэффективной 
при большом числе дескрипторов. Подробнее это рассматривает- 
ся в работе [Вапва ап4 Мовш 1998], (В этой работе приводится 
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еще один пример возникновения трудностей при экстраполяции 
результатов, полученных в локальной сети, на глобальную. Эта 
тема обсуждалась в совете 12.) Проблема большого числа де- 
скрипторов стоит особенно остро, когда ожидается немного 
событий на многих дескрипторах, то есть первый аргумент — 
тахЕаА - велик, но с помощью ЕР_5$ЕТ было зарегистрировано 
всего несколько дескрипторов. Это связано с тем, что ядро долж- 
но проверить все возможные дескрипторы (0, ..., тах), чтобы 
понять, ожидаются ли приложением события хотя бы на одном 
из них. В вызове ро11 используется массив дескрипторов, 
с помощью которого ядру сообщается о том, в каких событиях за- 
интересовано приложение, так что этой проблемы не возникает. 


Итак, использование зе1есе или ро11 позволяет мультиплексировать не- 
сколько событий ввода/вывода. Сложнее обстоит дело с несколькими таймерами, по- 
скольку в вызове можно указать лишь одно значение тайм-аута. Чтобы решить эту 
проблему и создать тем самым более гибкое окружение для событийно-управляе- 
мых программ, следует разработать вариант вызова зе1есЕ — Езе1ес®. Хотя 
функции Е 1щеочцё и ипЕ1меочце, связанные с Езе1ес%, построены по той же схе- 
ме, что и одноименные подпрограммы ядра ОМХ, они работают в адресном про- 
странстве пользователя и используют зе1есЕ для мультиплексирования ввода/ 
вывода и получения таймера. 

Таким образом, существуют три функции, ассоциированные с Е зе1есе. Прежде 
всего это сама сзе1есЕ, которая применяется аналогично зе1ес® для мульти- 
плексирования ввода/вывода. Единственное отличие в том, что у Езе1ес® нет 
параметра Е 1теоце (это пятый параметр зе1есЕ). События таймера задаются 
с помощью вызова функции &1теоце. которая позволяет указать длительность 
таймера и действие, которое следует предпринять при его срабатывании. Вызов 
ире1теоче отменяет таймер до срабатывания. 

Порядок вызова этих функций описан следующим образом: 


| 116 Езе1есе( 1пЕ махЁа, Еа_зеё *гатазК, ЕЯ_зебк *игтазк, Е94_зеЕ *ехтазКк ); | 
Возвращаемое значение: число готовых событий, 0 — если событий нет, —1 -| 
[о иОко: | 


и1519леа 116 Е1теоце( Уо1Я ( *Рапа]1ег )( уо1а * ), уо1@ *ага, 11 пв ); | 
Возвращаемое значение: идентификатор таймера для передачи ип 1теоце ] 


уо1А чпЕ1теоцЕ ( ипз1оапея 106 Езпегта ); | 
Е: 


Когда срабатывает таймер, ассоциированный с вызовом Е 1теоч®, вызывается 
функция, заданная параметром Вапа1екг, которой передается аргумент, заданный 
параметром аго. Таким образом, чтобы организовать вызов функции геегапзм1 Е 
через полторы секунды с целым аргументом зоск, нужно сначала написать 
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Е1меозё ( гебхгапзи16, ( уо1а * ) воск, 1500 ); 


а затем вызывать Е зе1ес®. Величина тайм-аута пз задается в миллисекундах, но 
надо понимать, что разрешающая способность системных часов может быть ниже, 
Для 9МХ-систем типичное значение составляет 10 мс, поэтому не следует ожи- 
дать от таймера более высокой точности. 

Примеры использования + зе1ес* будут приведены далее, а пока рассмотрим 
ее реализацию. В листинге 3.14 приведено определение структуры Е еуепе _Е 
и объявления глобальных переменных. 


Листинг 3. 14. Глобальные данные для 5е[есЕ 


{ 


очмяию,оы ьъ в 


ТЕ 


Езе1есЕ.с 


#1пс1ае "ебср.В" 
#аеЁ1пе МТТМЕК$ 25 


суредеЁ зегисе сеуепе_6 Сеуепе_; 
зегисе Ееуепе_6 


СеуепЕ_6 *пехе; 

зЕкгисЕе 61тмеуа1 %у; 

Уо1а ( *Ешпс }( уол1а * }; 
\Уо1а *агсд; 

ипз1апеа 106 19а; 


12 зсаб1с Сеуепе_© *асблуе = МОШ; /* Активные таймеры. */ 
13 эбаб1с сеуепЕ © *Егее_1156 = МОЬЬ; /* Неактивные таймеры. */ 


Езе]1есЕЁ.с 


Объявления 


2 


3-11 


12 


13 


Константа МТТМЕВ$ определяет, сколько таймеров выделять за один раз. 
Сначала таймеров нет вовсе, поэтому при первом обращении к Е 1щеоцЕ 
будет выделено МТТМЕВ$ таймеров. Если все они задействованы и про- 
исходит очередное обращение к Е 1меоцк, то выделяется еще МТТМЕВ$ 
таймеров. 

Каждый таймер представляет отдельную структуру типа сеуепе_+. 
Структуры связаны в список полем пехе. В поле 6у хранится время 
срабатывания таймера. Поля Ёчпс и агд предназначены для хранения 
указателя на функцию обработки события таймера (которая вызыва- 
ется при срабатывании) и ее аргумента. Наконец, идентификатор ак- 
тивного таймера хранится в поле 14, 

Порядок расположения активных таймеров в списке определяется мо- 
ментом срабатывания. Глобальная переменная асЕ1у\е указывает на 
первый таймер в списке. 

Неактивные таймеры находятся в списке свободных. Когда функции 
Е 1щеоце нужно получить новый таймер, она берет его из этого списка. Гло- 
бальная переменная Ггее_115Е указывает на начало списка свободных. 
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Далее изучим функцию & 1теоце и подпрограммы выделения таймеров (лис- 


тинг 3.15). 
Листинг 3.15. Функции Итеои! и а!№осае_итег 
Езе]есЕЁ.с 
1 зЕае1с беуепЕ_6 *а1]1осабе_Е1тег( у%о1а )} 
2 { 
3 сеуепЕ_6 *Ер; 
4 1Е ( Егее_1136 == МОШЬ ) /* нужен новый блок таймеров? */ 
5 { 
6 Егее_11зЕ = па11ос( МТТМЕЕ$ * $17еоЁ( веуепе_6 ) ); 
7 1Е ( Егее_1136 == МОШ ) 
8 еггог( 1, 0, "не удалось получить таймеры\п" }); 
9 Еог ( Ер = Егее_1156; 
10 р < Егее_11$6 + МТТМЕВ$ - 1; %&р++ } 
11 ср->пехе = р + 1; 
12 Ер->пехе = М; 
13 } 
14 Ер = Егее_1136; /* Выделить первый. */ 
15 Егее_1136 = Ер->пехе; /* Убрать его из списка. */ 
16 гебцтп 6р; 
17 } 
18 ипз1дпея 1пЕ в1теоце( уо1а ( *Еапс )( чо1а * }), уо1а *ага, 1пе пз ) 
19 { 
20 беуепе_6 *®р; 
21 Сеуепе_6 *Есаг; 
22 Сеуепе_Е **Ергет; 
23 5сае1с цп$1опеЯ 116 19 = 1; /* Идентификатор таймера. */ 
24 Ср = а11осабе_Е1тег(); 
25 Ер->Елас = Еапс; 
26 Ср->агд = ага; 
27 1Е ( дебес1теоЕдау( &Ер->6\у, МЫ ) <0) 
28 еггог( 1, еггпо, "Е1теоце: ошибка вызова деее1теоЁдау" ); 
29 Ср->Е\.ЕуУ_изес += мз * 1000; 
30 1Е ( Ср->6У.6У_ивес > 1000000 ) 
31 { 
32 Ер->Е\у.су_вес += Ер->6у.ву_цзес / 1000000; 
33 Ер->Еу.6м_ивес %= 1000000; 
34 } 
35 ог ( Ергеу = басе1уе, Есиг = асе1уе; 
36 Ссиг && !Сцмегстр( &6р->6\У, &бсиг->еУ, < }); /* ХХХ */ 
37 Сргеу = &Есиг->пехе, Есак = бсаг->пехе ) 
38 а 
39 *Ергеу = %р; 
40 Ср->пехЕе = ссиг; 
41 Ер->1а = 19++; /* Присвоить значение идентификатору таймера. */ 
42 гесаги Ер->1а; 
43 } 


Езе]есё.с 
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а!осйе_Нтег 


4-13 


14-16 


Функция а11осаее_е1мег вызывается из Е 1меоце для получения свобод- 
ного таймера. Если список свободных пуст, то из кучи выделяется память 
для МИМЕК$ структур ЕеуепЕ_, и эти структуры связываются в список. 
Выбираем первый свободный таймер из списка и возвращаем его вы- 
зывающей программе. 


Нтеоц: 


24-26 
27-34 


35-38 


Получаем таймер и помещаем в поля Рипс и ага значения переданных 
нам параметров. 

Вычисляем момент срабатывания таймера, прибавляя значение пара- 
метра пз к текущему времени. Сохраняем результат в поле &у. 

Ищем в списке активных место для вставки нового таймера. Вставить 
таймер нужно так, чтобы моменты срабатывания всех предшествующих 
таймеров были меньше либо равны, а моменты срабатывания всех по- 
следующих — больше момента срабатывания нового. На рис. 3.6 показан 


В начале поиска 


Непосредственно 
перед вставкой 


Рис. 3.6. Список активных таймеров до и после поиска точки вставки 
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27-34 


процесс поиска и значения переменных Е сиг и 6ргеу. Вставляем новый 
таймер так, что его момент срабатывания  ‹„ Удовлетворяет условию & 
ЗЕ ЗЕ, < 6. Обведенный курсивом прямоугольник & „„ показывает 
позицию в списке, куда будет помещен новый таймер. Несколько стран- 
ное использование макроса & 1пегспр в строке 36 связано с тем, что вер- 
сия в файле м1пзосК2 .Н некорректна и не поддерживает оператора >= 

Вставляем новый таймер в нужное место, присваиваем ему идентифи- 
катор и возвращаем этот идентификатор вызывающей программе. Воз- 
вращается идентификатор, а не адрес структуры $ еуепЕ_&, чтобы из- 
бежать «гонки» (гасе сопЯ оп). Когда таймер срабатывает, структура 
сеуеп+_6 возвращается в начало списка свободных. При выделении 
нового таймера будет использована именно эта структура. Если прило- 
жение теперь попытается отменить первый таймер, то при условии, что 
возвращается адрес структуры, а не индекс, будет отменен второй тай- 


‘мер. Эту проблему решает возврат идентификатора. 


Идентификатор таймера, возвращенный в конце функции из листинга 3.15, 
используется функцией ипЕ1теоце (листинг 3.16). 


Листинг 3.16. Функция ипитеош 


Езе1есё.с 
1 уо1а цчпЕ1меоце ( цпз1апея 116 1а ) 
2 { 
3 СеуепЕ_{ **Ергеу; 
4 СеуерЕ_{ *Есцх; 
5 Еог ( Ергеу = басе1уе, Есуцг = асё1\уе; 
6 Есиг && 1А != Есаг->1а; 
7 Ергеу = &Есиг->хпехЕе, Есиг = бсаг->рехё } 
В а 
9 1Е ( Есичг == М ) 
10 { 
11 еггог (0, 0, 
12 "при вызове ипё1щеоце указан несуществующий таймер (%а)\п", 14а}; 
3 гесиагп; 
14 } 
15 *Сргеу = Есиу->пехе; 
16 Есчг->пехЕ = Егее_115%; 
17 Гуее_115®6 = Есик; 
18 } 
Езе]есё.с 
Поиск таймера 
5-8 Ищем в списке активных таймер с идентификатором 19. Этот цикл по- 
хож на тот, что используется в Е 1теоче (листинг 3.15). 
9-14 — Если в списке нет таймера, который пытаемся отменить, то выводим 


диагностическое сообщение и выходим. 
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Отмена таймера 


15-17 Для отмены таймера исключаем структуру +еуепе_& из списка актив- 
ных и возвращаем в список свободных. 


Последняя из функций, работающих с таймерами, - это Е зе1есе (листинг 3.17) 


Листинг 3. 17. Функция 1зе/ес{ 


Езе1есЁ.с 
1106 63е1есе( 116 пахр1, ЕЯ_зеЕ *ге, ЕЯ_зеЕ *ме, Еа_зеЕ *ее } 
{ 


ый 

2 

3 ЕЯ_взеЕ гмазк; 

4 ЕЯ_веЕ змазКк; 

5 Еа_зеЕ емазКк; 

6 зЕгисЕ Е1меуа1 пои; 
7 зЕГасе Е1теуа1 6%; 

8 зЕГИСЕ 61теуа1 *Е\ур; 
9 СеуепЕ_6 *6р; 

10 ИЕ т: 


11 1Е (те ) 


12 гмазк = *ге; 

13 1Е (ме ) 

14 уттазк = *ме; 

15 1Е (ее ) 

16 етазКк = *ее; 

Ни ОЕ: 

18 { 

19 1Е ( дчесс1меоЕЧау( &пом, МОШЬ )} < 0) 

20 еггог( 1, еггпо, "6 зе1есе: ошибка вызова дее1теоЕаау" )}; 
21 \р11е ( асе1уе && !Е1мегспр( &пом, басЕе1уе->Ёу, < ) ) 
22 { 

23 асб1уе->Еопс( асе1уе->ага }; 

24 Ер = асетуе; 

25 асе1уе = асе1уе->пехе; 

26 ср->пехЕ = Егее_1136; 

27 Егее_1186 = %р; 

28 } 

29 1Е ( асблуе ) 

30 { 

За Су.Еу_зес = асб1уе->6у.ву_зес - пом.ву_зес;; 
32 Бу, СУ _изес = асб1уе->бу.бу_мвес - пом.ву_мзес; 
33 1Е ( Су.6у извес < 0) 

34 { 

35 СУ.бу извес += 1000000; 

36 Су. Су_зес--; 

Эа } 

38 СУ: = “У: 
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40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 } 


е1зе 1Ё (ге == МОШЬ && ме == МО, && ее == МЫ ) 


гесагп 0; 
е1зе 
бур = М; 


п = зе1есе( пахр1, ге, ме, ее, ур ); 
о О 
гебауй -1; 
1Е (п>О0) 
гебцгп п; 
1Е { те) 
*ге = гтазк; 
1Е (ме ) 
*ме = утазк; 
1ЁЕ (ее ) 
*ее = етазк; 


Езе1есё.с 


Сохранение масок событий 


11-16 


Поскольку при одном обращении к + зе1ес+ может несколько раз вы- 
зываться зе1есе, сохраняем маски событий, передаваемых зе1есе. 


Диспетчеризация событий таймера 


19-28 


Хотя в первой структуре кеуепЕ_*, находящейся в списке активных 
таймеров, время срабатывания меньше или равно текущему времени, 
вызываем обработчик этого таймера, исключаем структуру из списка ак- 
тивных и возвращаем в список свободных. Как и в листинге 3.15, стран- 
ный вызов макроса &1техгспр обусловлен некорректной его реализа- 
цией в некоторых системах. 


Вычисление времени следующего события 


29-39 


40-41 


42-43 


Если список активных таймеров не пуст, вычисляем разность между 
текущим моментом времени и временем срабатывания таймера в нача- 
ле списка. Это значение передаем системному вызову зе1еск. 

Если больше таймеров нет и нет ожидаемых событий ввода/вывода, 
то Езе1есе возвращает управление. Обратите внимание, что возвра- 
щается нуль, тем самым извещается об отсутствии ожидающих собы- 
тий. Семантика кода возврата отличается от семантики зе1есе. 

Если нет событий таймера, но есть события ввода/вывода, то устанав- 
ливаем сур в МОД, чтобы зе1ес+ не вернулся из-за тайм-аута. 


Вызов 5е/ес! 


44-48 


Вызываем зе1еск, чтобы он дождался события. Если зе1ес® заверша- 
ется с ошибкой, то возвращаем код ошибки приложению. Если зе1есЕ 
возвращает положительное значение (произошло одно или более со- 
бытий ввода/вывода), то возвращаем приложению число событий. По- 
скольку вызывали зе1есь, передавая указатели на маски событий, под- 
готовленные приложением, то биты событий в них уже установлены. 
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49-54 Если зе1ес® вернул нуль, то сработал один или несколько таймеров. 
Поскольку в этом случае зе1ес® обнулит все маски событий, установ- 
ленные приложением, восстановим их перед тем, как возвращаться 
к началу цикла, где вызываются обработчики таймеров. 


Для вставки и удаления таймеров из списка был использован линейный поиск. 
При небольшом числе таймеров это не страшно, но при увеличении их числа произ- 
водительность программы снижается, так как для поиска требуется О(п) операций, 
где п — число таймеров (для запуска обработчика события требуется время порядка 
О(1)). Вместо линейного поиска можно воспользоваться пирамидой [Зедвеулск 
1998] - для вставки, удаления и диспетчеризации требуется О(]08 п) операций - или 
хэширующим кольцом таймеров (Ваз шя Ипипя \Пее!) [Уагерезе ап4 ГасиКк 1997]; 
при этом эффективность может достигать О(1) для всех трех операций. 

Заметим, что функция Е зе1ес® не требует наличия ожидающих событий вво- 
да/вывода, поэтому ее вполне можно использовать только как механизм организа- 
ции тайм-аутов. В данном случае имеем следующие преимущества по сравнению 
с системным вызовом $з1еер: 


о всистеме ОМХ з1еер позволяет задерживать исполнение на интервал, крат- 
ный секунде, то есть разрешающая способность очень мала. В УЛп4о\з такого 
ограничения нет. Во многих реализациях МХ есть иные механизмы с более 
высокой степенью разрешения, однако они не очень распространены. Хоте- 
лось бы иметь механизм таймеров с высокой степенью разрешения, работаю- 
щий на возможно большем числе платформ. Поэтому в ОМХ принято исполь- 
зовать для реализации высокоточных таймеров вызов зе1есе; 

О применение з1еер или «чистого» зе1ес® для организации нескольких тай- 
меров затруднительно, поскольку требует введения дополнительных струк- 
тур данных. В функции 6 зе1есе все это уже сделано. 


К сожалению, в УЛп4о\/з функция Е зе1есе в качестве таймера работает не со- 
всем хорошо. В спецификации УЛпзоск АРТ [УЛпзосКк Стоир 1997] говорится, 
что использование зе1ес+ в качестве таймера «неудовлетворительно и не име- 
ет оправданий». Хотя на это можно возразить, что «неудовлетворительность» — 
это когда системный вызов работает не так, как описано в опубликованной специ- 
фикации, все же придется придерживаться этой рекомендации. Тем не менее мож- 
но использовать функцию Езе1есё и связанные с ней под УЛп4о\з, только при 
этом следует указывать также и события ввода/вывода. 


Резюме 


В этом разделе обсуждены преимущества, которые дает управляемость при- 
ложения событиями. Разработан также обобщенный механизм работы с таймера- 
ми, не накладывающий ограничений на количество таймеров. 


Совет 21. Подумайте, не сделать ли приложение 
событийно-управляемым (2) 


Здесь будет продолжено обсуждение, начатое в совете 20, а также проиллюстри- 
ровано использование функции с зе1есЕ в приложениях и рассмотрены некоторые 
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другие аспекты событийно-управляемого программирования. Вернемся к архи- 
тектуре с двумя соединениями из совета 19. 

Взглянув на программу хочцЕ2 (листинг 3.13), вы увидите, что она не управля- 
ется событиями. Отправив сообщение удаленному хосту, вы не возвращаетесь 
к чтению новых данных из стандартного ввода, пока не придет подтверждение. 
Причина в том, что таймер может сбросить новое сообщение. Если бы вы взвели 
таймер для следующего сообщения, не дождавшись подтверждения, то никогда не 
узнали бы, подтверждено старое сообщение или нет. 

Проблема, конечно, в том, что в программе хоцЕ2 только один таймер и поэтому она 
не может ждать более одного сообщения в каждый момент, Воспользовавшись Е зе1еск, 
вы сможете получить несколько таймеров из одного, предоставляемого зе1есе. 

Представьте, что внешняя система из совета 19 — это шлюз, отправляющий 
сообщение третьей системе по ненадежному протоколу. Например, он мог бы по- 
сылать датаграммы в радиорелейную сеть. Предположим, что сам шлюз не дает 
информации о том, было ли сообщение успешно доставлено. Он просто переправ- 
ляет сообщение и возвращает подтверждение, полученное от третьей системы. 

Чтобы в какой-то мере обеспечить надежность, новый писатель хоцё 3 повторно 
посылает сообщение (но только один раз), если в течение определенного времени не 
получает подтверждения. Если и второе сообщение не подтверждено, хоч 3 прото- 
колирует этот факт и отбрасывает сообщение. Чтобы ассоциировать подтверждение 
с сообщением, на которое оно поступило, хоцЕЗ включает в каждое сообщение не- 
кий признак. Конечный получатель сообщения возвращает этот признак в составе 
подтверждения. Начнем с рассмотрения секции объявлений хочЕЗ (листинг 3.18). 


Листинг 3. 18. Объявления для программы хо! 3 


хоцЕЗ.с 
1 #аеЕ1те АСК 0х6 /* Символ подтверждения АСК. */ 
2 #деЕ1пе МВ5й 128 /* Максимальное число неподтвержденных */ 
/* сообщений. */ 
3 #аеЕ1те Т1 3000 /* Ждать 3 с до первого АСК */ 
4 #ЗеЕ1те Т2 5000 /* и 5 с до второго АСК. */ 
5 #аеЕ1пе АСК$7 ( з17еоЁ( и_1132%) +1) 
6 ГуреаеЕ зЕкцсЕ /* Пакет данных. */ 
У 
8 и_11632_Е ]еп; /* Длина признака и данных. */ 
9 и_ 116326 соок1е; /* Признак сообщения. */ 
10 слав БЕГ 128: ]* /* Сообщение. */ 
11 } расКее_(; 
12 суреаеЕ зЕекасё /* Структура сообщения. */ 
13 { 
14 раскКеЕе_Е ркЕ; /* Указатель на сохраненное сообщение. */ 
15 1пЕ 1а; /* Идентификатор таймера. */ 


16 } изакес_Е; 


17 эзЕаЕ1с мзагес_6 пк[ МВУй ]; 
18 эзсаб1с сОСКЕТ в; 


——————и о ————————ииииыыы—=меЕЗ.с 
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Объявления 


5 


6-11 


12-16 


17 


Признак, включаемый в каждое сообщение, - это 32-разрядный поряд- 
ковый номер сообщения. Подтверждение от удаленного хоста опреде- 
ляется как АЗСП-символ АСК, за которым следует признак подтверж- 
даемого сообщения. Поэтому константа А$С2 вычисляется как длина 
признака плюс 1. 

Тип раскее 6 определяет структуру посылаемого пакета. Поскольку 
сообщения могут быть переменной длины, в каждый пакет включена 
длина сообщения. Удаленное приложение может использовать это поле 
для разбиения потока данных на отдельные записи (об этом шла речь 
в совете 6). Поле 1еп - это общая длина самого сообщения и признака. 
Проблемы, связанные с упаковкой структур, рассматриваются в заме- 
чаниях после листинга 2.45. 

Структура изагес_Е содержит структуру раскеЕ_, посланную уда- 
ленному хосту. Пакет сохраняется на случай, если придется послать его 
повторно. Поле 19 - это идентификатор таймера, выступающего в роли 
таймера ретрансмиссии для этого сообщения. 

С каждым неподтвержденным сообщением связана структура изагес_Е. 
Все они хранятся в массиве пх. 


Теперь обратимся к функции та1п программы хочЕЗ (листинг 3.19). 


Листинг 3. 19. Функция тат программы хои 3 


хоиЕЗ. Сс 


106 ма1п( 116 агас, сваг **акду ) 


Еа_зеЕ а11тгеа@аз; 
Еа_зеб геа@тазКк; 
шзагес Е *пр; 

106 кс; 

106 пла; 

ЛиЕ спЕ = 0; 
и_110632_Е шзала = 0; 
сВаг аск[] АСК$А |; 


тмтт(); 
$ = Еср_ с11епе( акду[ 1 ], ахау[Г 2 ] ); 
ЕР РЕВО( &а1]геааз ); 
ЕО СЕТ( 5$, &ба11геааз )}; 
ЕО ЗЕТ( 0, &а11]хеааз )}; 
Гок ( пр = шк; пр < пе + МВ5$а; пр++ ) 
пр->ркКЕе.1еп = -1; 
ОЕ Е 
т 
теаатазКк = а11тгеа@з; 
гс = ЕзетесЕе( з + 1, яхгеаатазеКк, МОБЬ, МОБ ); 
1Е (тс < 0) 
егготг( 1, егкпо, "ошибка вызова Езе1есё" }; 
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24 1Е (с == } 
25 еггог( 1, 0, "Езе1есЕ сказала, что нет событий\п" ); 
26 1Е ( ЕО _Т5ЗЕТ( 5, &геаатазКк ) ) 
27 { 
28 гс = гесу( в, аск + спЕ, АСКЛ - СПЕ, 0); 
29 1Е (ус == 0) 
30 еггог( 1, 0, "сервер отсоединился\п" ); 
31 е1 зе 1Е (тс < 0) 
32 еггог( 1, егхпо, "ошибка вызова гесу" ); 
33 1Е ( ( спЕ += гс ) < АСК$2 ) /* Целое сообщение? */ 
34 сопЕ1пие; /* Нет, еще подождем. */ 
35 спё = 0; /* В следующий раз новое сообщение. */ 
36 1Е ( аск[Г 0 ] != АСК ) 
37 { 
38 еггог( 0,0, "предупреждение: неверное подтверждение\п" ) 
39 сопё1пае; 
40 } 
41 пешсру ( &01Я, асКк + 1, з12еоЁ( ц_110632_+ ) }; 
42 пр = Е1патзагес( пла }; 
43 1Е (пр != МЪЬ ) 
44 { 
45 ипё1теоце ( пр->1а ); /* Отменить таймер. */ 
46 Егеепзагес( пр ); /* Удалить сохраненное сообщение. */ 
47 } 
48 } 
49 1Е ( ЕО_ТУЗЕТ( 0, &геаамазк ) )} 
50 { 
51 пр = деЕЕгеегес(); 
в гс = геаа( 0, пр->ркЕ.БаЕ, °12еоЕЁ( пр->ркЕ.БаЕ )} ); 
53 ТЕ те = 0) 
54 еггог( 1, еггпо, "ошибка вызова геа@а" ); 
55 пр->рке.БаЕ[ гс ] = '\0'; 
56 пр->ркё.соок1е = шза1а++; 
57 пр->ркё.1еп = №Еоп1( $з1хеоЁ( ц_110632_Е ) + кс ); 
58 1Е ( зепа( $, &пр->рКЕ, 
59 2 * в1хеоЁ( ч_10Е32_6 ) +тс, 0) < 0} 
60 еггог( 1, егупо, "ошибка вызова зепа" }); 
61 пр->1а = б1иеочЕ( ( боЕапс_6 )1оз6_АСК, пр, Т1 ); 
62 } 
63 } 
64 } 
хоиЕЗ. с 
Инициализация 


11-15 Так же, как и в программе хоцЕ2, соединяемся с удаленным хостом 
и инициализируем маски событий для Е зе1еск, устанавливая в них 
биты для дескрипторов 5 @1лп и сокета, который возвратила Еср_с14епё. 

16-17 Помечаем все структуры пзагес_‹ как свободные, записывая в поле 
длины пакета —1. 


Событийно-управляемое приложение 


18-25 Вызываем Е зе1есе точно так же, как зе1есЕ, только не передаем по- 


следний параметр (времени ожидания). Если Е зе1есё возвращает 
ошибку или нуль, то выводим диагностическое сообщение и заверша- 
ем программу. В отличие от зе1есё возврат нуля из Е зе1ес® -— свиде- 
тельство ошибки, так как все тайм-ауты обрабатываются внутри. 


Обработка входных данных из сокета 


26-32 


33-35 


36-40 


41-42 


При получении события чтения из сокета ожидаем подтверждение. 
В совете 6 говорилось о том, что нельзя применить гесу в считывании 
АЗСЯ7, байт, поскольку, возможно, пришли еще не все данные. Нельзя 
воспользоваться и функцией типа геадп, которая не возвращает управ- 
ления до получения указанного числа байт, так как это противоречило 
бы событийно-управляемой архитектуре приложения, - ни одно собы- 
тие не может быть обработано, пока геадл не вернет управления. По- 
этому пытаемся прочесть столько данных, сколько необходимо для завер- 
шения обработки текущего подтверждения. В переменной спе хранится 
число ранее прочитанных байт, поэтому А$С@ - спё — это число недо- 
стающих байт. 

Если общее число прочитанных байт меньше А$С7, то возвращаемся 
к началу цикла и назначаем 6 зе1есЕ ожидание прихода следующей 
партии данных или иного события. Если после только что сделанного 
вызова гес\у подтверждение получено, то сбрасываем спё в нуль вожи- 
дании следующего подтверждения (к этому моменту не было прочита- 
но еще ни одного байта следующего подтверждения). 

Далее, в соответствии с советом 11, выполняем проверку правильнос- 
ти полученных данных. Если сообщение - некорректное подтвержде- 
ние, печатаем диагностическое сообщение и продолжаем работу. Возмож- 
но, здесь было бы правильнее завершить программу, так как удаленный 
хост послал неожиданные данные. 

Наконец, извлекаем из подтверждения признак сообщения, вызываем 
Е1патздгес для получения указателя на структуру мзахгес_*, ассоци- 
ированную с сообщением, и используем ее для отмены таймера, после 
чего освобождаем пзагес_. Функции Е1пдтздгес и Ёгеетзагес при- 
ведены в листинге 3.20. 


Обработка данных из стандартного ввода 
21-57 Когда Е зе1есЕ сообщает о событии ввода из зЕ91п, получаем струк- 


туру пзагес_ и считываем сообщение в пакет данных. Присваиваем 
сообщению порядковый номер, пользуясь счетчиком пза1 а, и сохра- 
няем его в поле соок1е пакета. Обратите внимание, что вызывать 
ВЕ оп1 не нужно, так как удаленный хост не анализирует признак, 
а возвращает его без изменения. Записываем в поля пакета полную 
длину сообщения вместе с признаком. На этот раз вызываем Не оп1, 
так как удаленный хост использует это поле для чтения оставшейся 
части сообщения (совет 28). 


7 В ВИ ИИ ШИН — Создание эффективных сетевых программ 


58-61 Посылаем подготовленный пакет удаленному хосту и взводим таймер 


ретрансмиссии, обращаясь к функции Е 1теоце. 


Оставшиеся функции программы хоцЕЗ приведены в листинге 3.20. 


Листинг 3.20. Вспомогательные функции программы хо! 3 


1 
2 
3 
4 
5 
6 
й 
8 


9 


10 
уе 
12 


13 
14 
5 
16 


17 
18 


19 
20 
и 
22 
23 
24 


25 
26 
ай 
28 
29 


30 
31 
за 
33 
34 
35 
36 


37 } 


хоцЕёЗ. с 


пзагес_6 *адееЁгеехгес( уол1а ) 


{ 


} 


{ 


} 


изакес_е *пр; 


Гог ( пр = пг; пр < пе + МВ5А; пр++ ) 
1Е ( пр->рКЕ.1еп == -1 ) /* Запись свободна? */ 
хебчуп пр; 
егког( 1, 0, "дееЁхеегес: исчерпан пул записей сообщений\п" ); 
геогр ММ; /* "Во избежание предупреждений компилятора. */ 


пзагес_е *Е1патзакес ( ч_1п632_6 паа ) 


шзакес_е *пр; 


Гог ( пр = шк; пр < шк + МА$2; пр++ ) 
1Е ( пр->рКе.1еп != -1 && пр->рке.сооКк1е == п4а ) 
хебихгп по; 
еггог( 0, 0, 
"Е1памзагес: нет сообщения, соответствующего АСК %а\п", пла ); 
гесагп МО; 


\у0о1а Ехеемзакес( пзагес_@ *пр ) 


1Е ( пр->ркЕ.1еп == -1 } 
еггог( 1, 0, "Егеемзагес: запись сообщения уже освобождена\п" }; 
пр->рке.1еп = -1; 


зсае1с \01аА Ягор( шзакес_е *пр ) 


{ 


} 


еггог( 0, 0, "Сообщение отбрасывается: %5", пр->рке.БаЕ } 
Егеепзагес ( пр }; 


зсае1с уо1А 1о5е_АСК( шзакес_6 *пр } 


{ 


еггох ( 0, 0, "Повтор сообщения: $5", пр->рке.БаЕ }; 
1Е ( взепа( 3, &пр->ркЕ, 
з12еоЕ( ц_1п632_6 ) + пЕой1( пр->рке.1еп ), 0) < 0) 
еггог( 1, еггпо, “потерян АСК: ошибка вызова зепа" }; 
пр->1А = Е1меоче ( ( боЕопс_6 )акор, пр, Т2 )}; 


хоиЕЗ, С 


Событийно-управляемое приложение Г | | |185) 


деНтгеегес 


1-9 Данная функция ищет свободную запись в таблице пг. Просматрива- 
ем последовательно весь массив, пока не найдем пакет с длиной -1. 
Это означает, что запись свободна. Если бы массив шг был больше, то 
можно было бы завести список свободных, как было сделано для запи- 
сей типа сеуепе_+ в листинге 3.15. 


Япатздгес 

10-18 Эта функция почти идентичная деё Ёгеегес, только на этот раз ищем 
запись с заданным признаком сообщения. 

Пеетзодгес 

19-24 Убедившись, что данная запись занята, устанавливаем длину пакета 
в —1, помечая тем самым, что теперь она свободна. 

гор 


25-29 Данная функция вызывается, если не пришло подтверждение на вто- 
рое посланное сообщение (см. 105 _АСК). Пишем в протокол диагнос- 
тику и отбрасываем запись, вызывая Егеетзагес. 


1051 АСК 


30-37 Эта функция вызывается, если не пришло подтверждение на первое 
сообщение. Посылаем сообщение повторно и взводим новый таймер ре- 
трансмиссии, указывая, что при его срабатывании надо вызвать функ- 
цию агор. 


Для тестирования хоцЕ3 напишем серверное приложение, которое случайным 
образом отбрасывает сообщения. Назовем этот сервер ехезуз (сокращение от ех(егпа] 
зу$ет — внешняя система). Его текст приведен в листинге 3.21. 


Листинг 3.21. Внешняя система 


ехёзу5.с 
1 #10пс1аае "еёср.В" 


2 #АеЕ1пе СООКТЕЗА 4 /* Так установлено клиентом. */ 


3 116 ма1п( 116 агас, срахг **агдау ) 


4 { 

5 ЗОСКЕТ 3; 

6 ЗОСКЕТ 51; 

7 106 гс; 

8 спаг БаЕ[ 128 |; 
9 ТмТТ(); 


10 $ = Еср_зегуег( МОШЬ, агау[ 1] }; 

11 31 = ассере( $, МШ., Ш ); 

12 1Е ( 113%а11АзосК( $1 } } 

13 еггог( 1, еггпо, "ошибка вызова ассере" ); 
14 згапа( 127 ); 

15 Рог (;; ) 


Создание эффективных сетевых программ 


16 { 
17 гс = геаЯугес( $1, БаЕЁ, за1хеоЕ( БаЕЁ ) ); 
18 ЗЕ (ис == ) 
19 еггог( 1, 0, "клиент отсоединился\п" ); 
20 Е (тс < 0) 
21 еггог( 1, еггпо, "ошибка вызова гесу" ); 
22 1ЁЕ ( гапа() % 100 < 33 ) 
23 сопЕ1пце; 
24 ит1е( 1, БаЕ + СООКТЕЗА, гс - СООКТЕЗА ); 
25 петмоуе ( раЕ + 1, БаЕЁ, СООКТЕ$А ); 
26 БЕ Г О ] = '\006'; 
27 1Е ( зепа( $1, РаЕ, 1 + СООКТЕЗА, 0} <0) 
28 егхгог( 1, егкгпо, "ошибка вызова зеп@а" )}; 
29 } 
ее. 

ехЁзу$.с 
Инициализация 


9-14 — Выполняем обычную инициализацию сервера и вызываем функцию 
згапа для инициализации генератора случайных чисел. 


Примечание Функция гапа из стандартной библиотеки С работает быстро 
и проста в применении, но имеет ряд нежелательных свойств. 
Хотя для демонстрации хоцЕЗ она вполне пригодна, но для серь- 
езного моделирования нужно было бы воспользоваться более раз- 
витым генератором случайных чисел [Кпшй 1998], 


17-21 Вызываем функцию геадугес для чтения записи переменной длины, 
посланной ходе 3. 

22-23 Случайным образом отбрасываем примерно треть получаемых сообщений. 

24-28 Если сообщение не отброшено, то выводим его на зЕ доц, сдвигаем 
в буфере признак на один символ вправо, добавляем в начало символ 
АСК и возвращаем подтверждение клиенту. 


Вы тестировали хочЕЗ, запустив ехЕзуз в одном окне и воспользовавшись 
конвейером из совета 20 в другом (рис. 3.7). 
Можно сделать следующие замечания по поводу работы хочЕЗ: 


О доставка сообщений по порядку не гарантирована. На примере сообщений 
17 и 20 на рис. 3.8 вы видите, что повторно посланное сообщение нарушило 
порядок; 

о можно было увеличить число повторных попыток, добавив счетчик попы- 
ток в структуру пзагес_е и заставив функцию 1озе_АСК продолжать по- 
пытки отправить сообщение до исчерпания счетчика; 

я легко модифицировать хоче З так, чтобы она работала по протоколу ОПР, 
а не ТСР. Это стало бы первым шагом на пути предоставления надежного 
ОЮОрР-сервиса (совет 8); 

О если бы приложение работало с большим числом сокетов (и использова- 
ло функцию $ зе1есе), то имело бы смысл вынести встроенный код геа@х 


Состояние ТИМЕ-\ММАТ 


| 187, 


в отдельную функцию. Такая функция могла бы получать на входе структу- 
ру, содержащую спе, указатель на буфер ввода (или сам буфер) и адрес фун- 
кции, которую нужно вызвать после получения полного сообщения; 

а в качестве примера хочцЕЗ, пожалуй, выглядит чересчур искусственно, осо- 
бенно в контексте совета 19, но так или иначе она иллюстрирует, как можно 
решить задачу, часто возникающую на практике. 


Ьза $ шр | хочЕЗ 1оса1ВовЕ 9000 Ьза $ ехЕвув 9000 

хое3: Повтор сообщения: пеззаде 3 пеззаае 1 

хоце3: Повтор сообщения: пеззаае 4 пеззаае 2 

хоцЕЗ: Повтор сообщения: пеззасае 5 пеззаае 3 

хоцё3: Сообщение отбрасывается: пеззаае 4 пеззаде 6 

хоцЕЗ: Сообщение отбрасывается: шеззаае 5 пеззаае 7 

хоие3: Повтор сообщения: пеззаае 11 пеззаае 8 

хоце3: Повтор сообщения: пеззаае 14 пеззаае 9 

хоцё3: Сообщение отбрасывается: пеззаае 11 пеззаае 10 

хоче3З: Повтор сообщения: пеззаае 16 пеззаае 12 

хопе3: Повтор сообщения: пеззасае 17 пеззаае 13 

хоце3: Сообщение отбрасывается: шеззаде 14 пеззаае 15 

хоцЕЗ: Повтор сообщения: пеззаае 19 пеззаае 18 

хоце3З: Повтор сообщения: пеззаае 20 пеззаае 17 

хопе3: Сообщение отбрасывается: шеззадае 16 пеззаае 21 

хоцЕЗ: Сервер отсоединился пеззаае 20 

Вхгокей р1фре пеззаае 23 

ьва $ ^С сервер остановлен 
Ьза $ 


Рис. 3.7. Демонстрация хои{ 3 


Резюме 


В этом и предыдущем разделах говорилось о событийно-управляемом про- 
граммировании и о том, как использовать вызов зе1ес® для реагирования на со- 
бытия по мере их поступления. В совете 20 разработана функция Е зе1еск, по- 
зволившая получить несколько логических таймеров из одного физического. Эта 
функция и используемые с ней функции © 1теоче и апе1теобе дают возможность 
задавать тайм-ауты сразу для нескольких событий, инкапсулируя внутри себя все 
сопутствующие этому детали. 

Здесь была использована функция + зе1еск, чтобы усовершенствовать пример 
из совета 19. Применение & зе1ес® позволило задавать отдельные таймеры ре- 
трансмиссии для каждого сообщения, посланного ненадежному удаленному хосту 
через сервер-шлюз хочЕЗ. 


Совет 22. Не прерывайте состояние ТИМЕ-\М/А!Т 
для закрытия соединения 


В этом разделе рассказывается о том, что такое состояние ТТМЕ-УГАТТ в прото- 
коле ТСР, для чего оно служит и почему не следует пытаться обойти его. 
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Поскольку состояние Т1МЕ- У\/АТТ запрятано глубоко в недрах конечного ав- 
томата, управляющего работой ТСР, многие программисты только подозревают 
о его существовании и смутно представляют себе назначение и важность этого со- 
стояния. Писать приложения ТСР/[Р можно, ничего не зная о состоянии Т1МЕ- 
МУТАГТ, но необходимо разобраться в странном, на первый взгляд, поведении при- 
ложения (совет 23). Это позволит избежать непредвиденных последствий. 

Рассмотрим состояние Т1МЕ-УУАПТ и определим, каково его место в работе 
ТСР-соединения. Затем будет рассказано о назначении этого состояния и его важ- 
ности, а также, почему и каким образом некоторые программисты пытаются обойти 
это состояние. В конце дано правильное решение этой задачи. 


Что это такое 


Состояние ТТМЕ-\УТА!Т наступает в ходе разрыва соединения. Помните (совет 
7), что для разрыва ТСР-соединения нужно обычно обменяться четырьмя сегмен- 
тами, как показано на рис. 3.8. 

На рис. 3.8 показано соединение между двумя приложениями, работающими 
на хостах 1 и 2. Приложение на хосте 1 закрывает свою сторону соединения, при 
этом ТСР посылает сегмент Е1МХ хосту 2. Хост 2 подтверждает Е1М сегментом АСК 
и доставляет ЕТМ приложению в виде признака конца файла ЕОЕ (предполагает- 
ся, что у приложения есть незавершенная операция чтения, - совет 16). Позже при- 
ложение на хосте 2 закрывает свою сторону соединения, посылая ЕТМ хосту 1, ко- 
торый отвечает сегментом АСК. 


Хост 1 Хост2 
Приложение 
закрывает 
соединение <Е> 
Приложение 
закрывает 
соединение 
Соединение 
ИМЕ-МА/Т закрыто 
(2мМ$ь) 
Соединение 
закрыто Рис. 3.8 


Разрыв соединения 


В этот момент хост 2 окончательно закрывает соединение и освобождает ре- 
сурсы. С точки зрения хоста 2, соединения больше не существует. Однако хост 1 не 
закрывает соединение, а переходит в состояние Т1МЕ-У\УГА!Т и остается в нем в те- 
чение двух максимальных продолжительностей существования сегмента (2МЗГ. — 
тахипит зевтепе Шейте). 


Состояние ТИМЕ-М/АИТ 11| | |189 


Примечание Максимальное время существования сегмента (М5Т.) — это мак- 
симальное время, в течение которого сегмент может оставать- 
ся в сети, прежде чем будет уничтожен. В каждой [Р-датаграмме 
есть поле ТТ (Нте-ю-йое — время жизни). Это поле уменьшается 
на единицу каждым маршрутизатором, через который проходит 
датаграмма. Когда ТТ, становится равным нулю, датаграмма 
уничтожается. Хотя официально ТИ, измеряется в секундах, 
в действительности это поле почти всегда интерпретируется 
маршрутизаторами как счетчик промежуточных узлов. В ВЕС 
1812 [ВаЁег 1995 ] этот вопрос обсуждается подробнее. 


Прождав время 2МЗТ, хост 1 также закрывает соединение и освобождает ре- 
сурсы. 
Относительно состояния ТТМЕ-УГАГТ следует помнить следующее: 


о обычно в состояние ТТМЕ-\УУА!Т переходит только одна сторона - та, что 
выполняет активное закрытие; 


Примечание Под активным закрытием понимается отправка первого НМ. 
Считается, что вторая сторона при этом выполняет пассив- 
ное закрытие. Возможно также одновременное закрытие, когда 
обе стороны закрывают соединение примерно в одно время, 
поэтому посланные ими ЫМ одновременно находятся в сети. 
В этом случае активное закрытие выполняют обе стороны, так 
что обе переходят в состояние ИМЕ- МАТ. 


ов ЕС 793 [Розе] 19815] М$Т. определено равным 2 мин. При этом соедине- 
ние должно оставаться в состоянии Т1ТМЕ-\УМА!Т в течение 4 мин. На прак- 
тике это обычно не так. Например, в системах, производных от В$О, МГ. 
равно 30 с, так что состояние ТТМЕ-У/А!Т длится всего 1 мин. Можно встре- 
тить и другие значения в диапазоне от 30 с до 2 мин; 

О если в то время, когда соединение находится в состоянии ТТМЕ-УАГТ, при- 
бывает новый сегмент, то таймер на 2М$Т. перезапускается. Это будет рас- 
сматриваться ниже. 


Зачем нужно состояние ПМЕ-И/АТ 
Состояние Т1МЕ-УГАПТ служит двум целям: 


О не дать соединению пропасть при потере последнего АСК, посланного ак- 
тивной стороной, в результате чего другая сторона повторно посылает ЕТУ; 

О дать время исчезнуть «заблудившимся сегментам», принадлежащим этому 
соединению. 


Рассмотрим каждую из этих причин. В момент, когда сторона, выполняющая 
активное закрытие, готова подтвердить посланный другой стороной ЕТУ, все дан- 
ные, отправленные другой стороной, уже получены. Однако последний АСК может 
потеряться. Если это произойдет, то сторона, выполняющая пассивное закрытие, 
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обнаружит тайм-аут и пошлет свой ЕПМ повторно (так как не получила АСК на 
последний порядковый номер). 

А теперь посмотрим, что случится, если активная сторона не перейдет в состоя- 
ние ТИМЕ-\УА[Т, а просто закроет соединение. Когда прибывает повторно передан- 
ный ЕПМ, у ТСР уже нет информации о соединении, поэтому он посылает в ответ 
ЕТ (сброс), что для другой стороны служит признаком ошибки, а не нормаль- 
ного закрытия соединения. Но, так как сторона, пославшая последний АСК, все- 
таки перешла в состояние Т1МЕ-\УМАТТ, информация о соединении еще хранит- 
ся, так что она может корректно ответить на повторно отправленный ЕМУ. 

Этим объясняется и то, почему 2МЗГ-таймер перезапускается, если в состоя- 
нии Т1МЕ-УА!Т приходит новый сегмент. Если последний АСК потерян, и дру- 
гая сторона повторно послала ЕТУ, то сторона, находящаяся в состоянии Т1МЕ- 
МТАГТ, еще раз подтвердит его и перезапустит таймер на случай, если и этот АСК 
будет потерян. 

Второе назначение состояния ТТМЕ-УМАТТ более важно. Поскольку 1ТР-дата- 
граммы могут теряться или задерживаться в глобальной сети, ТСР использует 
механизм подтверждений для своевременной повторной передачи неподтвержден- 
ных сегментов (совет 1). Если датаграмма просто задержалась в пути, но не поте- 
ряна, или потерян подтверждающий ее сегмент АСК, то после прибытия исход- 
ных данных могут поступить также и повторно переданные. ТСР в этом случае 
определяет, что порядковые номера поступивших данных находятся вне текущего 
окна приема, и отбрасывает их. 

А что случится, если задержавшийся или повторно переданный сегмент придет 
после закрытия соединения? Обычно это не проблема, так как ТСР просто отбросит 
данные и пошлет В$Т. Когда К$Т дойдет до хоста, отправившего задержавшийся сег- 
мент, то также будет отброшен, поскольку у этого хоста больше нет информации 
о соединении. Однако если между этими двумя хостами установлено новое соедине- 
ние с такими же номерами портов, что и раньше, то заблудившийся сегмент может 
быть принят как принадлежащий новому соединению. Если порядковые номера дан- 
ных в заблудившемся сегменте попадают в текущее окно приема нового соединения, 
то данные будут приняты, следовательно, новое соединение — скомпрометировано. 

Состояние ТТМЕ-\АПТ предотвращает такую ситуацию, гарантируя, что два 
прежних сокета (два [Р-адреса и соответствующие им номера портов) повторно не 
используются, пока все сегменты, оставшиеся от старого соединения, не будут 
уничтожены. Таким образом, вы видите, что состояние ТП МЕ-УТАПТ играет важ- 
ную роль в обеспечении надежности протокола ТСР, Без него ТСР не мог бы га- 
рантировать доставку данных по порядку и без искажений (совет 9). 


Принудительная отмена состояния ТИМЕ-У/А/Т 


К сожалению, иногда можно досрочно выйти из состояния Т1ТМЕ-\УМАП. Это 
называется принудительной отменой (ТТМЕ-\УМА!ПТ аззаззтайоп) и бывает случай- 
но или намеренно. 

Сначала посмотрим, как это может произойти случайно. По стандартам 
ВЕС 793, если соединение находится в состоянии ТТМЕ-У/АПТ и приходит В$Т, 
то соединение должно быть немедленно закрыто. Предположим, что имеется 
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соединение в состоянии Т1МЕ-\У/АПТ и приходит старый сегмент-дубликат, кото- 
рый ТСР не принимает (например, потому, что порядковый номер оказался вне 
окна приема). ТСР посылает в ответ АСК, в котором указано, какой порядковый 
номер он ожидает (следующий за номером сегмента ЕТХ, посланного другой сто- 
роной). Ноу хоста на другой стороне уже нет информации о соединении, поэтому 
на этот АСК он отвечает сегментом К$Т. Когда этот К$Т приходит хосту, у кото- 
рого соединение находится в состоянии Т1МЕ-\УА!Т, тот немедленно закрывает 
соединение, — состояние Т[МЕ-У/А1Т принудительно отменено. 

Эта ситуация описана в ВЕС 1337 [Вгадеп 1992Ъ], где также рассматриваются 
трудности, сопряженные с принудительной отменой состояния Т1МЕ-У/АГТ Опас- 
НОСТЬ состоит в ВОЗМОЖНОСТИ «воскрешения» старого соединения (то есть появле- 
ния соединения с теми же двумя сокетами), что может привести к подтверждению 
старых данных, десинхронизации соединения с входом в бесконечный цикл и коши- 
бочному завершению нового соединения. 

Это легко предотвратить, изменив протокол ТСР так, чтобы в состоянии Т[МЕ- 
УТАТТ было разрешено игнорировать В$Т. Хотя такое изменение, рекомендован- 
ное в ВЕС 1337, официально не одобрено, тем не менее в некоторых стеках оно 
реализовано. 

Принудительно отменить состояние ТПМЕ-У/АГТ можно и намеренно. С по- 
мощью опции сокета 50_ГТМСЕВ программист требует немедленного закрытия со- 
единения даже в том случае, когда приложение выполняет активное закрытие. 
Этот сомнительный прием иногда рекомендуют применять, чтобы вывести «упав- 
ший» сервер из состояния Т[МЕ-\УМАГТ и запустить его заново. Подробнее об этой 
проблеме и более правильном способе ее решения будет рассказано в совете 23. 
Корректно написанное приложение никогда не должно манипулировать состояни- 
ем ТТМЕ-\У/АГТ, поскольку это неотъемлемая часть механизма обеспечения надеж- 
ности ТСР. 

Обычно, когда приложение закрывает соединение, вызов с1озе или с1озезоскее 
возвращается немедленно, даже если в буфере передачи еще есть данные. Разуме- 
ется, ТСР будет пытаться доставить эти данные, но приложение не имеет информа- 
ции, удалось ли это. Чтобы решить эту проблему, можно установить опцию сокета 
50_РТМСЕВ. Для этого следует заполнить структуру 11пдех и вызывать зеё зосКоре 
с параметром $0_РЬТМСЕК. 

В большинстве ОМХ-систем структура 11пдег определена в заголовочном 
файле /азг/1пс1аае/зуз/зоскее .Н. В системе УЙп4о\ она находится в файле 
\1пзоск2 .НВ. В любом случае она выглядит так: 


зЕхасЕ 11паех { 
106 1 опоЕЕ; /* Включить/выключить опцию. */ 
106 1_11паег; /* Время задержки. */ 


р 


Если поле 1_опоЕЕ равно нулю, то опция задержки отключается, и выбирает- 
ся поведение по умолчанию - вызов с1озе или с1озезосКее возвращается немед- 
ленно, а ядро продолжает попытки доставить еще не переданные данные. Если же 
] опоЕЕ не равно нулю, то работа зависит от значения поля 1_11пдек. Если 
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1_11пдег отлично от нуля, то считается, что это время, в течение которого ядро 
должно подождать отправки и подтверждения оставшихся в буфере передачи 
данных. При этом с1озе или с1озезоскее не возвращается, пока данные не бу- 
дут доставлены или не истечет указанное время. 

Если к моменту завершения ожидания данные еще не доставлены, то с1озе 
или с1озезоскее возвращает код ЕИООЪОВЬСОСК, и недоставленные данные могут 
быть потеряны. Если все данные уже доставлены, то оба вызова возвращают нуль. 


Прамечание К сожалению, семантика поля 1_11пдег зависит от реализа- 
ции. В Уп4ош$ и некоторых реализациях ИМХ это число се- 
кунд, на которое следует задержать закрытие сокета. В сис- 
темах, производных от В5О, это число тактов таймера (хотя 
в документации сказано, что это число секунд). 


Используя опцию $0_Т/ТМСЕВ таким способом, вы гарантируете, что данные 
будут доставлены уровню ТСР на удаленном хосте. Но они не обязательно будут 
прочитаны приложением. Более правильный способ добиться последнего — ис- 
пользовать процедуру аккуратного размыкания, описанную в совете 16. 

Если поле 1_11пдег равно нулю, то соединение разрывается. Это означает, что 
хосту на другом конце посылается В5Т, и соединение закрывается немедленно, не 
переходя в состояние Т1МЕ-\УАПТ. Это преднамеренная принудительная отмена 
состояния ТТМЕ-УГАПТ, о которой упоминалось выше. Как было сказано, это опас- 
ный прием, который в обычном приложении применять не следует. 


Резюме 


В этом разделе обсуждено состояние ТТМЕ-УМАИТ, которое часто понимают 
неправильно. Это состояние — важная часть механизма обеспечения надежности 
протокола ТСР, и попытки обойти его неверны. Преждевременный выход из со- 
стояния ТПМЕ-\У/АТТ может быть обусловлен «естественным» стечением обсто- 
ятельств в сети или программой, которая манипулирует опцией $0_ТТМСЕК. 


Совет 23. Сервер должен устанавливать опцию 
5О_КЕЦЧ$ЗЕАООК 


В сетевых конференциях очень часто задают вопрос: «Когда сервер «падает» 
или нормально завершает сеанс, я пытаюсь его перезапустить и получаю ошибку 
«АЧ@гезз атеаду ш изе». А через несколько минут сервер перезапускается нормаль- 
но. Как сделать так, чтобы сервер рестартовал немедленно?» Чтобы проиллюст- 
рировать эту проблему, напишем сервер эхо-контроля, который будет работать 
именно так (листинг 3.22). 


Листинг 3.22. Некорректный сервер эхо-контроля 


БаЯзегуег.с 
1 #1осТтаае "“еЕср.В" 


2 11Е ма1п( 116 агас, саг **акау ) 


Установка опции $О_ВЕЦ$ЕАООК ЧТГТТ [| |193. 


а 

4 зЕгисЕ зосКа@ак_1п 1оса1; 

5 ЗОСКЕТ в; 

6 ЗОСКЕТ $1; 

7 ИЕ +2; 

8 спахг БаЕЁ[ 1024 ]; 

9 ТМТТ(); 
10 $ = зоскее( РЕ_ТМЕТ, $ОСК_5ТВЕАМ, 0}; 
11 1Е ( 1!15уа11азосКк( зв ) ) 
12 еггог( 1, еггпо, "Не могу получить сокет" ); 
13 Ь2его( &1оса1, $12еоЁ( 1оса1 } )}; 


14 1оса1.51п_ЁЕат11у = АР_ТМЕТ; 

15 1оса1.51п_рогб = ИЕоп$( 9000 ); 

16 1оса1.51п_ааах.з_аЧахг = Пбоп1( ТМАРРВ_АМУ ); 
17 1Е ( Б1та( $, ( з6ЕгасЕ зоскаааг * )&1оса1, 


18 $12ео0оЁ( 1оса1 ) } < 0} 

19 еггог( 1, еггпо, "Не могу привязать сокет" ); 
20 1Е ( 11з6еп( <, МТ$ТЕМ ) <0 } 

21 еггохг( 1, егхгпо, "ошибка вызова 1156еп" ); 


22 51 = ассере( в, №, М ); 
23 1Е ( 1!1зуа11Я9зосКк( $1 )} ) 


24 егхгог( 1, егкпо, "ошибка вызова ассере" }; 

25 ОЕ. 2) 

26 { 

27 гс = гесу( 1, БаЁ, з1хеоЁ( БЕ ), 0); 

28 1Е (тс <0) 

29 егхгохг( 1, еггпо, "ошибка вызова гесу" }; 
30 1Е (кс == 0) 

31 еггох( 1, 0, "Клиент отсоединился\п" ); 

32 тс = зепа( $1, БЕ, гс, 0}; 

33 1Е (тс < 0) 

34 еггохг( 1, еггпо, "ошибка вызова зепра" ); 
35 } 

36 } 


Ьаа5егуег.с 


На первый взгляд, сервер выглядит вполне нормально, только номер порта 
«зашит» в код. Если запустить его в одном окне и соединиться с ним с помощью 
программы &епеф, запущенной в другом окне, то получится ожидаемый результат. 
(На рис. 3.9 опущены сообщения (е|пе{ об установлении соединения.) 

Проверив, что сервер работает, останавливаете клиента, переходя в режим ко- 
манд {еше и вводя команду завершения. Обратите внимание, что если немед- 
ленно повторить весь эксперимент, то будет тот же результат. Таким образом, 
Ъаазегуег перезапускается без проблем. 

А теперь проделайете все еще раз, но только остановите сервер. При попытке 
перезапустить сервер вы получите сообщение «АЯ@гез$ агеаду ш изе» (сообщение 
разбито на две строчки). Разница в том, что во втором эксперименте вы останови- 
ли сервер, а не клиент - рис. 3.10. 


7. ВВ ИИ ШИ ШИИ — Создание эффективных сетевых программ 


Ьза $ Баавекуек Ьза $ Ее1пеЕ 1оса1Вове 9000 
Баазегуег: Клиент отсоединился | Ве11о 

Ьза $: Баавегкуег Ве1]1о 

фаазегуек: Клиент отсоединился | ^] 

Ъза $ се]1пеё> ац1Е Клиент завершил сеанс. 


Соппесе1оп с1овзеа 
Сервер перезапущен. 
Ьза $ ве1пееё 1оса1пове 9000 
мог1а 
мог1а 
^] 
се1пеё> аа1Е Клиент завершил сеанс. 
Соппесе1оп с1озеа 
Ьза $ 


Рис. 3.9. Завершение работы клиента 


Ъза $ Баавегуех Ьза $ ве1теё 1оса]1товЕ 9000 

^С Сервер остановлен Бе11о ада1п 

Ьза $ Баавекуегк Бе11о адалп 

Баавегуег: Не могу привязать сокет: СоппесЕ1оп с1озеа Бу 
Еоге1ап Бозе 

Ааагезз а1геаау 1п пзе (48) Ьза $ 

Ьза $ 


Рис. 3.10. Завершение работы сервера 


Чтобы разобраться, что происходит, нужно помнить о двух вещах: 


О состоянии ТТМЕ-УМАГТ протокола ТСР; 
о ТСР-соединение полностью определено четырьмя факторами (локальный 
адрес, локальный порт, удаленный адрес, удаленный порт). 


Как было сказано в совете 22, сторона соединения, которая выполняет актив- 
ное закрытие (посылает первый ЕП), переходит в состояние ТТМЕ-\УМАТТ и оста- 
ется в нем в течение 2М$ТГ.. Это первый ключ к пониманию того, что вы наблюда- 
ли в двух предыдущих примерах: если активное закрытие выполняет клиент, то 
можно перезапустить обе стороны соединения. Если же активное закрытие выпол- 
няет сервер, то его рестартовать нельзя. ТСР не позволяет это сделать, так как пре- 
дыдущее соединение все еще находится в состоянии Т1МЕ-УГАГТ. 

Если бы сервер перезапустился и с ним соединился клиент, то возникло бы 
новое соединение, возможно, даже с другим удаленным хостом. Как было сказа- 
но, ТСР-соединение полностью определяется локальными и удаленными адреса- 
ми и номерами портов, так что даже если с вами соединился клиент с того же уда- 
ленного. хоста, проблемы не возникнет при другом номере удаленного порта. 


Примечание Даже если клиент с того же удаленного хоста воспользуется 
тем же номером порта, проблемы может и не возникнуть. Тра- 
диционно реализация В$О разрешает такое соединение, если 
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только порядковый номер посланного клиентом сегмента 5УМ 
больше последнего порядкового номера, зарегистрированного со- 
единением, которое находится в состоянии ИМЕ- МА/Т. 


Возникает вопрос: почему ТСР возвращает ошибку, когда делается попытка 
перезапустить сервер? Причина не в ТСР который требует только уникальности 
указанных факторов, а в АР] сокетов, требующем двух вызовов для полного опре- 
деления этой четверки. В момент вызова Ъ1п4 еще неизвестно, последует ли за 
ним соппесе, и, если последует, то будет ли в нем указано новое соединение, или 
он попытается повторно использовать существующее. В книге [Тогек 1994] ав- 
тор - и не он один — предлагает заменить вызовы Ь1па, соппесё и 11:6 еп одной 
функцией, реализующей функциональность всех трех. Это даст возможность ТСР 
выявить, действительно ли задается уже используемая четверка, не отвергая попы- 
ток перезапустить закрывшийся сервер, который оставил соединение в состоя- 
нии Т1МЕ-\УМА!Т. К сожалению, элегантное решение Торека не было одобрено. 

Но существует простое решение этой проблемы. Можно разрешить ТСР при- 
вязку к уже используемому порту, задав опцию сокета $0_ВЕИЗЕАРРВ. Чтобы про- 
верить, как это работает, вставим между строками 7 и 8 файла Бадзегуег .с строку 


соп$е 106 оп = 1; 
а между строками 12 и 13 - строки 


1ЁЕ ( зебзосКоре( $, $01._$ОСКЕТ, $0_ВЕЧОЗЕАРОВ, &оп, 
$12е0оЁ( оп } } } 
егхгохг( 1, ехггкпо, "ошибка вызова зеезосКкоре" ); 


Заметьте, что вызов зе зоскоре должен предшествовать вызову 51 па. Если на- 
звать исправленную программу доодзегуег и повторить эксперимент (рис. 3.11), 
то получите такой результат: 


Ьза $ доойвегуек Ьза $ ве1тее 1оса1Вов® 9000 
^С Сервер остановлен. Ве11о опсе ада1п 
Ьза $ Бе11о опсе ада1п 


СорпесЕ1оп с1озеа Бу Еоге1ап Позё 
Сервер перезапущен. 

ЬзЯ $ ее1тее 1оса1Вове 9000 

Ве11о опе 1авЕ Е1ле 

Бе11о опе 1азе Е1ме 


Рис. 3.11. Завершение работы сервера, в котором используется опция ЗО_НЛЕЧЗЕАВОН 


Теперь вы смогли перезапустить сервер, не дожидаясь выхода предыдущего 
соединения из состояния ТТМЕ-У/АПТ. Поэтому в сервере всегда надо устанавли- 
вать опцию сокета $0_ВЕПЗЕАРРВ. Обратите внимание, что в предлагаемом карка- 
сеи в функции кср_зегуег это уже делается. 

Некоторые, в том числе авторы книг, считают, что задание опции 50_ВЕОЗЕАРОВ 
опасно, так как позволяет ТСР создать четверку, идентичную уже используемой, 
и таким образом создать проблему. Это ошибка. Например, если попытаться создать 
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два идентичных прослушивающих сокета, то ТСР отвергнет операцию привязки, 
даже если вы зададите опцию 50_ВЕПЗЕАОБВ: 


Ъза $ двооавегуег & 

[1] 1883 

Ъза $ дооавегуег 

дооЯзегуег: Не могу привязать сокет: АЯагезз а1геа@у 1п цзе (48) 
за $ 


Аналогично если вы привяжете одни и те же локальный адрес и порт к двум 
разным клиентам, задав 50_ВЕОЗЕАОВВ, то Ь1па для второго клиента завершится 
успешно. Однако на попытку второго клиента связаться с тем же удаленным хос- 
том и портом, что и первый, ТСР ответит отказом. 

Помните, что нет причин, мешающих установке опции 5$0_ВЕПЗЕАРЛЬ в серве- 
ре. Это позволяет перезапустить сервер сразу после его завершения. Если же этого 
не сделать, то сервер, выполнявший активное закрытие соединения, не перезапус- 
тится. 


Прамечание В книге [1е0еп5 1998 ] отмечено, что с опцией 50_КЕПОЗЕАПГК свя- 
зана небольшая проблема безопасности. Если сервер привязывает 
универсальный адрес ТМАРОК_АМУ, как это обычно и делается, то 
другой сервер может установить опцию 50_КЕИЗЕАРОРК и привя- 
зать тот же порт, но с конкретным адресом, ‹похитив» тем 
самым соединение у первого сервера. Эта проблема действитель- 
но существует, особенно для сетевой файловой системы (МЕ5) 
даже в среде ОМХ, поскольку МЕб привязывает порт 2049 из 
открытого всем диапазона. Однако такая опасность существу- 
ет не из-за использования МЕ$ опции 50_ВЕПОЗЕАРПК, а потому 
что это может сделать другой сервер. Иными словами, эта опас- 
ность имеет место независимо от установки 50_КЕЦЗЕАРОК, 
так что это не причина для отказа от этой опции. 


Следует отметить, что у опции $0_ВЕЙЗЕАООВ есть и другие применения. 
Предположим, например, что сервер работает на машине с несколькими сетевы- 
ми интерфейсами и ему необходимо иметь информацию, какой интерфейс кли- 
ент указал в качестве адреса назначения. При работе с протоколом ТСР это легко, 
так как серверу достаточно вызвать дчеезосКпаше после установления соедине- 
ния. Но, если реализация ТСР/ТР не поддерживает опции сокета ТР_ВЕСУОЗТАРОВ, 
то ООР-сервер так поступить не может. Однако ФОР-сервер может решить эту зада- 
чу, установив опцию $50_ВЕЧЗЕАОВВ и привязав свой хорошо известный порт к конк- 
ретным, интересующим его интерфейсам, а универсальный адрес ТМАРОВ_АМУ — ко 
всем остальным интерфейсам. Тогда сервер определит указанный клиентом адрес 
по сокету, в который поступила датаграмма. 

Аналогичная схема иногда используется ТСР- и ООР-серверами, которые хо- 
тят предоставлять разные варианты сервиса в зависимости от адреса, указанного 
клиентом. Допустим, вы хотите использовать свою версию Е сртах (совет 18) для 
предоставления одного набора сервисов, когда клиент соединяется с интерфейсом 
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по адресу 198.200.200.1, и другого — при соединении клиента с иным интерфей- 
сом. Для этого запускаете экземпляр Есрмих со специальными сервисами на ин- 
терфейсе 198.200.200.1, а экземпляр со стандартными сервисами - на всех осталь- 
ных интерфейсах, указав универсальный адрес ТМАООВ_АМУ. Поскольку Есрмих 
устанавливает опцию $0_ВЕОЗЕАОВВ, ТСР позволяет повторно привязать порт 1, 
хотя при второй привязке указан универсальный адрес. 

И, наконец, 50_КЕЦЗЕАООВ используется в системах с поддержкой группового 
вещания, чтобы дать возможность одновременно нескольким приложениям про- 
слушивать входящие датаграммы, вещаемые на группу. Подробнее это рассматри- 
вается в книге [{еуепз 1998]. 


Резюме 


В этом разделе рассмотрена опция сокета $0_ВЕОЗЕАООВ. Ее установка позво- 
ляет перезапустить сервер, от предыдущего «воплощения» которого еще осталось 
соединение в состоянии Т1МЕ-\У/А[Т. Серверы должны всегда устанавливать эту 
опцию, которая не влечет угрозу безопасности. 


Совет 24. По возможности пишите один большой 
блок вместо нескольких маленьких 


Для этой рекомендации есть несколько причин. Первая очевидна и уже обсуж- 
далась выше: каждое обращение к функциям записи (иг1 ее, зепа и т.д.) требует, 
по меньшей мере, двух контекстных переключений, а это довольно дорогая опера- 
ция. С другой стороны, многократные операции записи (если не считать случаев 
типа записи по одному байту) не требуют заметных накладных расходов в прило- 
жении. Таким образом, совет избегать лишних системных вызовов — это, скорее, 
«правила хорошего тона», а не острая необходимость. 

Есть, однако, и более серьезная причина избегать многократной записи мел- 
ких блоков — эффект алгоритма Нейгла. Этот алгоритм кратко рассмотрен в сове- 
те 15. Теперь изучим его взаимодействие с приложениями более детально. Если не 
принимать в расчет алгоритм Нейгла, то это может привести к неправильному ре- 
шению задач, так или иначе связанных с ним, и существенному снижению произ- 
водительности некоторых приложений. 

К сожалению, алгоритм Нейгла, равно как и состояние Т1МЕ-\У\АПТ, многие 
программисты понимают недостаточно хорошо. Далее будут рассмотрены причи- 
ны появления этого алгоритма, способы его отключения и предложены эффектив- 
ные решения, которые обеспечивают хорошую производительность приложению, 
не оказывая негативного влияния на сеть в целом. 

Алгоритм был впервые предложен в 1984 году Джоном Нейглом (КЕС 896 
[Мазе 1984]) для решения проблем производительности таких программ, как {епеё 
и ей подобных. Обычно эти программы посылают каждое нажатие клавиши в от- 
дельном сегменте, что приводит к засорению сети множеством крохотных дата- 
грамм (Ипузгатз). Если принять во внимание, что минимальный размер ТСР-сег- 
мента (без данных) равен 40 байт, то накладные расходы при посылке одного 
байта в сегменте достигают 4000%. Но важнее то, что увеличивается число 
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пакетов в сети. А это приводит к перегрузке и необходимости повторной передачи, 
из-за чего перегрузка еще более увеличивается. В неблагоприятном случае в сети 
находится несколько копий каждого сегмента, и пропускная способность резко сни- 
жается по сравнению с номинальной. 

Соединение считается простаивающим, если в нем нет неподтвержденных дан- 
ных (то есть хост на другом конце подтвердил все отправленные ему данные). 
В первоначальном виде алгоритм Нейгла должен был предотвращать описанные 
выше проблемы. При этом новые данные от приложения не посылаются до тех пор, 
пока соединение не перейдет в состояние простоя. В результате в соединении не 
может находиться более одного небольшого неподтвержденного сегмента. 

Процедура, описанная в ВЕС 1122 [ Вгадеп 1989] несколько ослабляет это тре- 
бование, разрешая посылать данные, если их хватает для заполнения целого сег- 
мента. Иными словами, если можно послать не менее М5$З байт, то это разрешено, 
даже если соединение не простаивает. Заметьте, что условие Нейгла при этом по- 
прежнему выполняется: в соединении находится не более одного небольшого не- 
подтвержденного сегмента. 

Многие реализации не следуют этому правилу буквально, применяя алгоритм 
Нейгла не к сегментам, а к операциям записи. Чтобы понять, в чем разница, пред- 
положим, что М5 составляет 1460 байт, приложение записывает 1600 байт, в ок- 
нах приема и передачи свободно, по меньшей мере, 2000 байт и соединение проста- 
ивает. Если применить алгоритм Нейгла к сегментам, то следует послать 1460 байт, 
а затем ждать подтверждения перед отправкой следующих 140 байт — алгоритм 
Нейгла применяется при посылке каждого сегмента. Если же использовать алго- 
ритм Нейгла к операциям записи, то следует послать 1460 байт, а вслед за ними 
еще 140 байт — алгоритм применяется только тогда, когда приложение передает 
ТСР новые данные для доставки. 

Алгоритм Нейгла работает хорошо и не дает приложениям забить сеть крохот- 
ными пакетами. В большинстве случае производительность не хуже, чем в реали- 
зации ТСР, в которой алгоритм Нейгла отсутствует. 


Примечание Представьте, например, приложение, которое передает ТСР 
один байт каждые 200 мс. Если период кругового обращения (КТТ) 
для соединения равен одной секунде, то ТСР без алгоритма Ней- 
гла будет посылать пять сегментов в секунду с накладными 
расходами 4000%. При наличии этого алгоритма первый байт 
отсылается сразу, а следующие четыре байта, поступившие от 
приложения, будут задержаны, пока не придет подтверждение 
на первый сегмент. Тогда все четыре байта посылаются сразу. 
Таким образом, вместо пяти сегментов послано только два, за 
счет чего накладные расходы уменьшились до 1600% при сохра- 
нении той же скорости 5 байт/С. 


К сожалению, алгоритм Нейгла может плохо взаимодействовать с другой, до- 
бавленной позднее возможностью ТСР -— отложенным подтверждением. 
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Когда прибывает сегмент от удаленного хоста, ТСР задерживает отправку 
АСК в надежде, что приложение скоро ответит на только что полученные данные. 
Поэтому АСК можно будет объединить с данными. Традиционно в системах, про- 
изводных от ВЭБ, величина задержки составляет 200 мс. 


Прамечание В ВЕС 1122 не говорится о сроке задержки, требуется лишь, 
чтобы она была не больше 500 мс. Рекомендуется также под- 
тверждать, по крайней мере, каждый второй сегмент. 


Отложенное подтверждение служит той же цели, что и алгоритм Нейгла — 
уменьшить число повторно передаваемых сегментов. 

Принцип совместной работы этих механизмов рассмотрим на примере типич- 
ного сеанса «запрос/ответ». Как показано на рис. 3.12, клиент посылает короткий 
запрос серверу, ждет ответа и посылает следующий запрос. 

Заметьте, что алгоритм Нейгла не применяется, поскольку клиент не посыла- 
ет новый сегмент, не дождавшись ответа на предыдущий запрос, вместе с которым 
приходит и АСК. На стороне сервера задержка подтверждения дает серверу время 
ответить. Поэтому для каждой пары запрос/ответ нужно всего два сегмента. Если 
через КТТ обозначить период кругового обращения сегмента, а через Т, — время, 

необходимое серверу для обработки запроса и отправки ответа (в миллисекундах), 
то на каждую пару запрос/ответ уйдет ВТТ + Т, мс. 

А теперь предположим, что клиент посылает Свой запрос в виде двух последова- 
тельных операций записи. Часто причина в том, что запрос состоит из заголовка, за 
которым следуют данные. Например, клиент, который посылает серверу запросы 
переменной длины, может сначала послать длину запроса, а потом сам запрос. 


Примечание Пример такого типа изображен на рис. 2.17, но там были приня- 
ты меры для отправки длины и данных в составе одного сегмента. 


На рис. 3.13 показан поток данных. 


Клиент Сервер 
Клиент Сервер 


Запрос (часть 1) 


200 мс 
Ответ + <А 200 мс 


} 200 мс 


Рис. 3.12. Поток данных из одиночных Рис. 3.13. Взаимодействие алгоритма 
сегментов сеанса «запрос/ответ» Нейгла и отложенного подтверждения 


200 мс 
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На этот раз алгоритмы взаимодействуют так, что число сегментов, посланных 
на каждую пару запрос/ответ, удваивается, и это вносит заметную задержку. 

Данные из первой части запроса посылаются немедленно, но алгоритм Нейгла 
не дает послать вторую часть. Когда серверное приложение получает первую часть 
запроса, оно не может ответить, так как запрос целиком еще не пришел. Это зна- 
чит, что перед посылкой подтверждения на первую часть должен истечь тайм-аут 
установленный таймером отложенного подтверждения. Таким образом, алгорит- 
мы Нейгла и отложенного подтверждения блокируют друг друга: алгоритм Нейг- 
ла мешает отправке второй части запроса, пока не придет подтверждение на первую, 
аалгоритм отложенного подтверждения не дает послать АСК, пока не сработает тай- 
мер, поскольку сервер ждет вторую часть. Теперь для каждой пары запрос/ответ 
нужно четыре сегмента и 2 Х КТТ +Т, + 200 мс. В результате за секунду можно 
обработать не более пяти пар запрос /ответ, даже если забыть о времени обработки 
запроса сервером и о периоде кругового обращения. 


Примечание Для многих систем это изложение чрезмерно упрощенное. На- 
пример, системы, производные от В$О, каждые 200 мс проверя- 
ют все соединения, для которых подтверждение было отложено. 
При этом АСК посылается независимо от того, сколько времени 
прошло в действительности. Это означает, что реальная задер- 
жка может составлять от 0 до 200 мс, в среднем 100 мс. Одна- 
ко часто задержка достигает 200 мс из-за «фазового эффекта», 
состоящего в том, что ожидание прерывается следующим так- 
том таймера через 200 мс. Первый же ответ синхронизирует 
ответы с тактовым генератором. Хороший пример такого по- 
ведения см. в работе [Матзрай её а/. 1999]. 


Последний пример показывает причину проблемы: клиент выполняет после- 
довательность операций «запись, запись, чтение». Любая такая последователь- 
ность приводит к нежелательной интерференции между алгоритмом Нейгла и алго- 
ритмом отложенного подтверждения, поэтому ее следует избегать. Иными словами, 
приложение, записывающее небольшие блоки, будет страдать всякий раз, когда 
хост на другом конце сразу не отвечает. 

Представьте приложение, которое занимается сбором данных и каждые 50 мс 
посылает серверу одно целое число. Если сервер не отвечает на эти сообщения, 
а просто записывает данные в журнал для последующего анализа, то будет наблю- 
даться такая же интерференция. Клиент, пославший одно целое, блокируется ал- 
горитмом Нейгла, а затем алгоритмом отложенного подтверждения, например на 
200 мс, после чего посылает по четыре целых каждые 200 мс. 


Отключение алгоритма Нейгла 


Поскольку сервер из последнего примера записывал в журнал полученные 
данные, взаимодействие алгоритмов Нейгла и отложенного подтверждение не 
принесло вреда и, по сути, уменышило общее число пакетов в четыре раза. Допустим, 
что клиент посылает серверу серию результатов измерения температуры, и сервер 
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должен отреагировать в течение 100 мс, если показания выходят за пределы допу- 
стимого диапазона. В этом случае задержка на 200 мс, вызванная интерференци- 
ей алгоритмов, уже нетерпима, и ее надо устранить. 

Хорошо, что ВЕС 1122 требует наличия метода, отключающего алгоритм Нейг- 
ла. Пример с клиентом, следящим за температурой, - это один из случаев, когда 
такое отключение необходимо. Менее драматичный, но более реалистичный при- 
мер относится к системе Х-МЛпдо\, работающей на платформе МХ. Поскольку 
Х использует протокол ТСР для общения между дисплеем (сервером) и приложе- 
нием (клиентом), Х-сервер должен доставлять информацию о действиях пользо- 
вателя (перемещении курсора мыши) Х-клиенту без задержек, вносимых алгорит- 
мом Нейгла. 

В АРГ сокетов можно отключить алгоритм Нейгла с помощью установки оп- 
ции сокета ТСР_МОБЕГАУ. 


соп$е 106 оп = 1; 
зеёзоскоре ( з, ТРРВОТО_ТСР, ТСР_МОБЕГАУ, &оп, з17еоЁ( оп ) ); 


Но возможность отключения алгоритма Нейгла вовсе не означает, что это обя- 
зательно делать. Приложений, имеющих реальные основания отключать алго- 
ритм, значительно меньше, чем тех, которые это делают без причины. Причина, по 
которой программисты с пугающей регулярностью сталкиваются с классической 
проблемой интерференции между алгоритмами Нейгла и отложенного подтверж- 
дения, в том, что делают много мелких операций записи вместо одной большой. 
Потом они замечают, что производительность приложений намного хуже, чем ожи- 
далось, и спрашивают, что делать. И кто-нибудь обязательно ответит: «Это все 
алгоритм Нейгла. Отключите его!». Нет нужды говорить, что после отключения 
этого алгоритма проблема производительности действительно исчезает. Только за 
это приходится расплачиваться увеличением числа крохотных пакетов в сети. 
Если так работают многие приложения или, что еще хуже, алгоритм Нейгла от- 
ключен по умолчанию, то возрастет нагрузка сети. В худшем случае это может 
привести к полному затору. 


Запись со сбором 


Как видите, существуют приложения, которые, действительно, должны от- 
ключать алгоритм Нейгла, но в основном это делается из-за проблем с производи- 
тельностью, причина которых в отправке логически связанных данных серией из 
отдельных операций записи. Есть много способов собрать данные, чтобы послать 
их вместе. Наконец всегда можно скопировать различные порции данных в один 
буфер, которые потом и передать операции записи. Но, как объясняется в совете 
26, к такому методу следует прибегать в крайнем случае. Иногда можно организо- 
вать хранение данных в одном месте, как и сделано в листинге 2.15. Чаще, однако, 
данные находятся в нескольких несмежных буферах, а хотелось бы послать их 
одной операцией записи. 

Для этого и в ЧМХ, и в УЛпзосКк предусмотрен некоторый способ. К сожале- 
нию, эти способы немного отличаются. В ИШХ есть системный вызов мг1®еу 
и парный ему вызов геадуУ. При использовании ит1ееу вы задаете список буферов, 


Создание эффективных сетевых программ 


из которых должны собираться данные. Это решает исходную задачу: можно 
размещать данные в нескольких буферах, а записывать их одной операцией, 
исключив тем самым интерференцию между алгоритмами Нейгла и отложен- 
ного подтверждения. 

#1пс1аае <зуз/ц1о.6> 


$5512е_Е мк1ееу( 106 ЕЯ, сопзе зЕкисЕ 1оуес *1оу, 1пЕ СПЕ }; 


5512е_Е геаЯуУ( 1пЕ Га, сопзЕ зегисЕ 1оуес *1оу, 1пЕ СПЕ }; 


Возвращаемое значение: число переданных байт или —1 в случае ошибки. 


Параметр гоу - это указатель на массив структур 1о\ес, в которых хранятся 
указатели на буферы данных и размеры этих буферов: 


вЕкисЕ 1оуес { 
сПаг *1оу_разе; /* Адрес начала буфера. */ 
$12е_© 1оу_1еп; /* Длина буфера. */ 

}; 


Примечание Это определение взято из системы ЕгееВ$Ш. Теперь во многих 
системах адрес начала буфера определяется так: 


уо1а *1оу_Базе; /* адрес начала буфера */ 


Третий параметр, спЁ - это число структур 1оуес в массиве (иными словами, 
количество буферов). 

У вызовов иг1ееу и геаду практически общий интерфейс. Их можно исполь- 
зовать для любых файловых дескрипторов, а не только для сокетов. 

Чтобы это понять, следует переписать клиент (листинг 3.23), работающий 
с записями переменной длины (листинг 2.15), с использованием иг16еу. 


Листинг 3.23. Клиент, посылающий записи переменной длины с помощью млйеу 


угсу.с 
1 #1пс1аае "еёср.Ь" 
2 #1пс]аае <зуз/и1о.Н> 


3 11Е ма1п( 116 агкас, сраг **агау } 


4 { 

5 ЗОСКЕТ $; 

6 106 п; 

7 сБаг БиЕ[ 128 ]; 

8 $ЕгисЕ 1оуес 10У[2 ]; 


9 1м1Т(); 

10 3 = Еср_с11епе( агау[ 1 ], агау[ 2 ] ); 
11 10У[ 0 ].1оУу_Базе = ( сваг * }&5п; 

12 10У[ 0 ].10У_1еп = з12еоЁЕ( п }; 

13 10оУ[ 1 ].1о0о%_Базе = БЕ; 


14 ир11е ( Едее$( БаЕ, эз12еоЕ( БаЕЁ }, зэка } != М ) 


Большой блок вместо нескольких маленьких 1 МММ Е] 


15 { 
16 10У[ 1 ].1о0ом_Т1еп = зЕг1еп( РаЕЁ ); 
17 п = 6оп1( 10оУ[ 1 ].1оу_1еп ); 
18 1Е ( мглЕеу( 3, 10%, 2 ) <О0) 
19 еггог( 1, еггпо, "ошибка вызова мг1®еу" }; 
20 } 
21 ЕХТТ( О ); 
22 } 
УГСУ. С 
Инициализация 


9-13 Выполнив обычную инициализацию клиента, формируем массив 
1оу. Поскольку в прототипе иг1{еу имеется спецификатор сопз& для 
структур, на которые указывает параметр 1о\%, то есть гарантия, что 
массив 1о\ не будет изменен внутри мг16еу, так что большую часть 
параметров можно задавать вне цикла \111е. 


Цикл обработки событий 


14-20 Вызываем ЕдеЕз для чтения одной строки из стандартного ввода, вы- 
числяем ее длину и записываем в поле структуры из массива 1оу. Кро- 
ме того, длина преобразуется в сетевой порядок байт и сохраняется 
в переменной п. 


Если запустить сервер угз (совет 6) и вместе с ним клиента угсу, то получат- 
ся те же результаты, что и раньше. 
В спецификации УЛпзосК определен другой, хотя и похожий интерфейс. 


#10с1аае <и1пвосКк2. > 


116 МЗААРТ ИМбАзепа( ЗОСКЕТ $, ГРИЗАВОЕ, ОМОВО спЕ, 
ЬРОМОКО зепё, ОМОВО Е1адз, БРИЗАОУЕВГАРРЕО оу], 
ГРИЗАОУЕВКГАРРЕО _СОМРГЕТТОМ_ВООТТМЕ Гипс ); 


Возвращаемое значение: 0 в случае успеха, в противном случае ЗОСКЕТ_ЕВВОВ. 


Последние два аргумента используются при вводе/выводе с перекрытием, 
и в данном случае не имеют значения, так что обоим присваивается значение МОЪГ.. 
Параметр РиЕ указывает на массив структур типа \ЗАВОЕ, играющих ту же роль, 
что структуры 1оуес в вызове мг1 ету. 


СуреаеЕ зехгисЕ _МЗАВИЕ { 

и_Топа1еп; /* Длина буфера. */ 

СсПаг РАВ * БаЕ; /* Указатель на начало буфера. */ 
} ИЗАВОЕ, ЕАВ * БРИУЗАВОЕ; 


Нараметр зепЁ - это указатель на переменную типа РИОКГ, в которой хранит- 
ся число переданных байт при успешном завершении вызова. Параметр Е1адз ана- 
логичен одноименному параметру в вызове зепа. 

Версия клиента, посылающего сообщения переменной длины, на платформе 
УЙЯп4ао\жз выглядит так (листинг 3.24): 


РУ ИИ ШИ — Создание эффективных сетевых программ 


Листинг 3.24. Версия угсу для ИИпзоск 


угсуи.с 

1 #1пс1аае "еЁёср.В" 

2 116 па1п( 116 агас, спаг **агау } 

Зах 

4 бОСКЕТ 3; 

5 116 п; 

6 срах ЪоЕЁ|[ 128 }]; 

7 ИЗАВИЕ м"раЕЁ[ 2 ]; 

8 ОМОВО зепс; 

9 ТМТТ(); 

10 $ = Еср_с11епе( агау[ 1 ], ахаду[ 2] ); 

11 мраЕ[ 0 ].ЪоаЕЁ = ( саг * )&1; 

12 ираЕ[ 0 )].1еп = з12еоЁ( тп); 

13 мраЕ[ 1 ].5аЕЁ = БаЕЁ; 
14 У111е ( Едеез( БаЁ, $12еоЁ( раЕЁ }, зеаш ) 1!= м. ) 

15 { 
16 ираЕ[ 1 ].1еп = з6у1еп( роЕЁ ); 
17 п = 560о01( ираЕ[ 1 ].1еп ); 
18 1Е ( ИЗАбепа( з, "ЪаЕЁ, 2, &зепЕ, 0, МБ, Ш ) <0) 
19 егхгохг( 1, еггпо, "ошибка вызова МЗАбета" ); 
20 } 
р Ех О): 
22 ) 
угсуи. с 


Как видите, если не считать иного обращения к вызову записи со сбором, то 
\УМпзоск-версия идентична ОМХ-версии. 


Резюме 


В этом разделе разобран алгоритм Нейгла и его взаимодействие с алгоритмом 
отложенного подтверждения. Приложения, записывающие в сеть несколько малень- 
ких блоков вместо одного большого, могут заметно снизить производительность. 

Поскольку алгоритм Нейгла помогает предотвратить действительно серьезную 
проблему — переполнение сети крохотными пакетами, не следует отключать его для 
повыщения производительности приложений, выполняющих запись мелкими блока- 
ми. Вместо этого следует переписать приложение так, чтобы все логические связан- 
ные данные выводились сразу. Здесь был рассмотрен удобный способ решения этой 
задачи с помощью системного вызова ят16еу в ОМХ или У5АЗепа в УЙпзоскК. 


Совет 25. Научитесь организовывать тайм-аут 
для вызова соппесе 


В совете 7 отмечалось, что для установления ТСР-соединения стороны 
обычно должны обменяться тремя сегментами (это называется трехсторонним 
квитированием). Как показано на рис. 3.14, эта процедура инициируется вызовом 


Организация тайм-аута для вызова соппес Я 


соппес® со стороны клиента и завершается, когда сервер получает подтвержде- 
ние АСК на посланный им сегмент ЗУМ. 


Примечание Возможны, конечно, и другие варианты обмена сегментами. На- 
пример, одновременный соппесь, когда сегменты 5УМ переда- 
ются навстречу друг другу. Но в большинстве случаев соедине- 
ние устанавливается именно так, как показано на рис. 3.14. 


Клиент Сервер 


Вызван соппес! 
<$УМ> 


АТТ 


соппес! вернул 
управление 


Рис. 3.14 Обычная процедура 
трехстороннего квитирования 


При использовании блокирующего сокета вызов соппесЕ не возвращает 
управления, пока не придет подтверждение АСК на посланный клиентом ЗУМ. По- 
скольку для этого требуется, по меньшей мере, время ВТТ, а при перегрузке сети 
или недоступности хоста на другом конце — даже больше, часто бывает полезно 
прервать вызов соппесе. Обычно ТСР делает это самостоятельно, но время ожи- 
дания (как правило, 75 с) может быть слишком велико для приложения. В некото- 
рых реализациях, например в системе $о]ат1$, есть опции сокета для управления 
величиной тайм-аута соппеск, но, к сожалению, они имеются не во всех системах. 


Использование вызова а[агт 


Есть два способа прерывания соппес\ по тайм-ауту. Самый простой - окру- 
жить этот вызов обращениями к а1агп. Предположим, например, что вы не хо- 
тите ждать завершения соппесе более пяти секунд. Тогда можно модифициро- 
вать каркас срс11епе.зКе1 (листинг 2.6), добавив простой обработчик сигнала 
и немного видоизменив функцию па1п: 


у0о1Я а1аги_пп@1к( 1пЕ э1а ) 
{ 


тебгагп; 


} 


1п1Е па1п( 116 агас, сВаг **агдау ) 


{ 


$19па1( $5ТСАБЕМ, а1акм_впа1х ); 
а1агш( 5 ); 


РИА ИИ ШИ ШИИИ — Создание эффективных сетевых программ 


гс = соппесе( $, ( зегисЕ зоскаааг * )&реег, з12еоЁ( реег ) ); 
а1аги( 0 ); 
1Е (ус <0) 
{ 
1Е ( егхгпо == ЕТМТЬ ) 
еггог( 1, 0, "истек тайм-аут соппесе\п" }; 


} 


Назовем программу, созданную по этому каркасу, соппес6о и попытаемся с ее 
помощью соединиться с очень загруженным \еБ-сервером УаВоо. Получится 
ожидаемый результат: 

Ъза: $ соппесЕео уабоо.сом аау&1те 


соппесЕёбо: истек тайм-аут соппесё спустя 5 с 
Ьза: $ 


Хотя это и простое решение, с ним связано две потенциальных проблемы. Сна- 
чала обсудим их, а потом рассмотрим другой метод -— он сложнее, но лишен этих 
недостатков. 

Прежде всего в данном примере подразумевается, что «тревожный» таймер, ис- 
пользуемый в вызове а1аги, нигде в программе не применяется, и, значит, для сиг- 
нала УТСАЬВМ не установлен другой обработчик. Если таймер уже взведен где-то 
еще, то приведенный код его переустановит, поэтому старый таймер не сработает. 
Правильнее было бы сохранить и затем восстановить время, оставшееся до сраба- 
тывания текущего таймера (его возвращает вызов а1агм), а также сохранить 
и восстановить текущий обработчик сигнала ЗТСАБВМ (его адрес возвращает вызов 
319па1). Чтобы все было корректно, надо было также получить время, проведен- 
ное в вызове соппеск, и вычесть его из времени, оставшегося до срабатывания 
исходного таймера. 

Далее, для упрощения вы завершаете клиент, если соппесе не вернул управ- 
ления вовремя. Вероятно, нужно было бы предпринять иные действия. Однако 
надо иметь в виду, что перезапустить соппесе нельзя. Дело в том, что в результате 
вызова соппес® сокет остался привязанным к ранее указанному адресу, так что 
попытка повторного выполнения приведет к ошибке «Ад4гезз агеа4у п изе». При 
желании повторить соппес®, возможно, немного подождав, придется сначала за- 
крыть, а затем заново открыть сокет, вызвав с1озе (или с1озезосКее) и зоскее. 

Еще одна потенциальная проблема в том, что некоторые ОМХ-системы мо- 
гут автоматически возобновлять вызов соппес& после возврата из обработчика 
сигнала. В таком случае соппесе не вернет управления, пока не истечет тайм-аут 
ТСР. Во всех современных вариантах системы ОХ поддерживается вызов 
$1часе1оп, который можно использовать вместо з1апа1. В таком случае следует 
указать, хотите ли вы рестартовать соппес*. Но в некоторых устаревших версиях 
ОМХ этот вызов не поддерживается, и тогда использование а1аги для прерыва- 
ния соппес® по Тайм-ауту затруднительно. 

Если нужно вывести всего лишь диагностическое сообщение и завершить се- 
анс, то это можно сделать в обработчике сигнала. Поскольку это происходит до рес- 
тарта соппесе, не имеет значения, поддерживает система вызов 51дас® оп или нет. 
Однако если нужно предпринять какие-то другие действия, то, вероятно, придется 


Организация тайм-аута для вызова соппесё ИЕ д 


выйти из обработчика с помощью функции 1опа)пр, а это неизбежно приводит 
к возникновению гонки. 


Примечание 


Следует заметить, что гонка возникает и в более простом слу- 
чае, когда вы завершаете программу. Предположим, что соеди- 
нение успешно установлено, и соппесЕ вернул управление. Од- 
нако прежде чем вы успели его отменить, таймер сработал, что 
привело к вызову обработчика сигнала и, следовательно, к завер- 
шению программы. 


а1агм( 5 ); 
гс = соппесе( в, МЛ, М ); 
/* здесь срабатывает таймер */ 
а1агм (0); 


Вы завершаете программу, хотя соединение и удалось устано- 
вить. В первоначальном коде такая гонка не возникает, посколь- 
ку даже если таймер сработает между возвратом из соппесЕ 
и вызовом а1агт, обработчик сигнала вернет управление, не 
предпринимая никаких действий. 


Принимая это во внимание, многие эксперты считают, что для прерывания 
вызова соппес® по тайм-ауту лучше использовать зе1есе. 


Использование 5е/ес: 


Другой, более общий метод организации тайм-аута соппес® состоит в том, 
чтобы сделать сокет неблокирующим, а затем ожидать с помощью вызова зе1есе. 
При таком подходе удается избежать большинства трудностей, возникающих при 
попытке воспользоваться а1аги, но остаются проблемы переносимости даже меж- 
ду разными ОМХ-системами. 

Сначала рассмотрим код установления соединения. В каркасе срс11епё.зке1 
модифицируйте функцию пма1пт, как показано в листинге 3.25. 


Листинг 3.25. Прерывание соппес{ по тайм-ауту с помощью 5е[ес! 


106 малт ( 


1 

2 

3 Еа_зеё 
4 Еа_зее 
Б Еа_зеё 
6 ЗЕКИСЕ 
7 зекисе 
8 ЗОСКЕТ 


соппесёЕо1.с 
106 агас, спаг **агах } 


таеуепез; 
игеуепез; 
ехеуепез; 
зоскааах_1п реег; 
Е1теуа1 %%х; 

8; 


9 106 Е1ааз; 


10 трЕ гс; 


11 ТА 


12 зеё_аЯЯагезв ( атгах [ 1 ] Р агау[ 2 ] ; &реех, "Еср" ) ; 
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13 $5 = зоскее( АР_ТМЕТ, $ОСК_ЭТВЕАМ, 0 }; 
14 1Е ( 1!1зуа11Азоск( з ) ) 
15 еггог( 1, еггпо, "ошибка вызова зосКеЕ " ); 
16 3Ё( ( Е1ааз = Ёспе1( 3, Е СЕТЕЦ, 0 } ) <0) 
17 еггог( 1, еггпо, "ошибка вызова Ёспбе1 (Е_ СЕТЕ)" ); 
18 1Ё ( Еспё1( 3, Е бЕТЕЬ, Е1адз | О_МОМВШОСК ) < 0) 
19 еггог( 1, еггпо, "ошибка вызова Ёспё1 (ЕР_ЗЕТЕЦ)" ); 
20 1Е ( (гс = соппесё( з, ( зегисЕе зоскаааг * }&реег, 
21 312еоЁ( реег ) } } && ехгхпо != ЕТМРВОСВЕЗЗ ) 
22 еггог( 1, ехгхгпо, "ошибка вызова соппесЕЁ" ); 
23 1ЁЕ (гс == 0 ) /* Уже соединен? */ 
24 { 
25 1ЁЕ ( Еспё1( з, Е_ЗЕТЕЦ, Еаа5 ) < 0) 
26 еггог( 1, еггпо, "ошибка вызова Ёспё1 (восстановление флагов)" 
); 
27 с11епё ( 5, &реег )}; 
28 ЕХТТ( 0); 
29 } 
30 ЕО _ЛЕКО( &хаеуепез ); 
31 ЕО _ЗЕТ( $, &гдеуепЕз )}; 
32 игеуепез = гаеуепез; 
33 ехеуепёз = гаеуепёз; 
34 бу. су _зес = 5; 
35 Су. су _чвес = 0; 
36 гс = зе1есе( з + 1, &гаеуепез, &игеуепез, бехеуепёз, &6% ); 
37 Е.С те =: 0) 
38 еггог( 1, еггпо, "ошибка вызова зе1есе" ); 
39 е1зе 1Ё ( гс == ) 
40 еггог( 1, 0, "истек тайм-аут соппесе\п" }; 
41 е1зе 1Ё ( 1зсоппесбеЯ( з, &г@аеуепез, &мгеуепез, бехеуепез ) ) 
42 { 
43 3Ё ( Еспё1( 3, Е ЗЕТЕЬ, Е1адз ) < 0) 
44 еггог( 1, еггпо, "ошибка вызова Ёспё1 (восстановление флагов)" 
| 
45 с11епе ( з, б&реех }; 
46 } 
47 е1зе 
48 еггог( 1, еггпо, "ошибка вызова соппесе" }; 
49 ЕХТТ( 0}; 
50 } 
соппесёёо1.с 
Инициализация 


16-19 Получаем текущие флаги, установленные для сокета, с помощью опе- 


рации ОВ, добавляем к ним флаг О_МОМВГОСК и устанавливаем новые 
флаги. 


Инициирование соппес 
20-29 Начинаем установление соединения с помощью вызова соппеск. По- 


скольку сокет помечен как неблокирующий, соппесЕ немедленно 


Организация тайм-аута для вызова соппесё {1 ИХ] 


возвращает управление. Если соединение уже установлено (это воз- 
можно, если, например, вы соединялись с той машиной, на которой за- 
пущена программа), то соппес® вернет нуль, поэтому возвращаем сокет 
в режим блокирования и вызываем функцию с11еп*. Обычно в момент 
возврата из соппесе соединение еще не установлено, и приходит код 
ЕТМРВОСВЕ$$. Если возвращается другой код, то печатаем диагности- 
ческое сообщение и завершаем программу. 


Вызов 5еесЕ 


30-36 Подготавливаем, как обычно, данные для зе1ес® и, в частности, уста- 
навливаем тайм-аут на пять секунд. Также следует объявить заинтере- 
сованность в событиях исключения. Зачем - станет ясно позже. 


Обработка код возврата 5е[ес 


37-40 Если зе1ес& возвращает код ошибки или признак завершения по тайм- 
ауту, то выводим сообщение и заканчиваем работу. В случае ответа 
можно было бы, конечно, сделать что-то другое. 

41-46 Вызываем функцию 1зсоппесв ед, чтобы проверить, удалось ли уста- 
новить соединение. Если да, возвращаем сокет в режим блокирования 
и вызываем функцию с11еп+. Текст функции 1зсоппесеей приведен 
в листингах 3.26 и 3.27. 

47-48 — Если соединение не установлено, выводим сообщение и завершаем сеанс. 


К сожалению, в ОМХ ив УЛп4до\’$ применяются разные методы уведомления 
об успешной попытке соединения. Поэтому проверка вынесена в отдельную функ- 
цию. Сначала приводится ОМХ-версия функции 15соппесвеа. 

В ОМС, если соединение установлено, сокет доступен для записи. Если же 
произошла опгибка, то сокет будет доступен одновременно для записи и для чте- 
ния. Однако на это нельзя полагаться при проверке успешности соединения, по- 
скольку можно возвратиться из соппес® и получить первые данные еще до обра- 
щения к зе1ес*. В таком случае сокет будет доступен и для чтения, и для записи — 
в точности, как при возникновении ошибки. 


Листинг 3.26. ИМХ-версия функции (5соппе ед 


соппесЕЕо1.с 


1 116 1зсорпесбея( соскЕТ з, ЕЯ_зеё *га, Еа_веё *мг, Г@а_взеф *ех ) 
24 

3 106 егг; 

4 106 1еп = з12еоЕ( егг ); 

5 еггпо = 0; /* Предполагаем, что ошибки нет. */ 

6 1Е ( !ЕО_Т5ЗЕТ( в, гЯ ) && '!ЕО_Т55ЕТ( в, мЕ ) ) 

7 теёоуй 0; 

8 1Е ( деЕезоскоре( в, $ОЬ_ЗОСКЕТ, $0О_ЕВВОВ, &ехх, &1еп ) < 0) 
9 хебагп 0; 
10 егхпо = егг; /* Если мы не соединились. */ 
11 гебогп егх == 0; 

12 } 


соппесЕЁо1.с 
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5-7 Если сокет не доступен ни для чтения, ни для записи, значит, соединение 
не установлено, и возвращается нуль. Значение еггпо заранее установ- 
лено в нуль, чтобы вызывающая программа могла определить, что сокет, 
действительно, не готов (разбираемый случай) или имеет место ошибка. 

8-11 Вызываем десзосКоре для получения статуса сокета. В некоторых вер- 
сиях МХ деезосКоре возвращает в случае ошибки -1. В таком случае 
записываем в еггпо код ошибки. В других версиях система просто воз- 
вращает статус, оставляя его проверку пользователю. Идея кода, ко- 


торый корректно работает в обоих случаях, позаимствована из книги 
[Збеуеп$ 1998]. 


Согласно спецификации УЛпзоск, ошибки, которые возвращает соппесе че- 
рез неблокирующий сокет, индицируются путем возбуждения события исключе- 
НИЯ В 5е1ес®. Следует заметить, что в МХ событие исключения всегда свиде- 
тельствует о поступлении срочных данных. Версия функции 1зсоппесееа для 
УЛп4о\$ показана в листинге 3.27. 


Листинг 3.27. ИИпаомз-версия функции 15соппецеа 


соппесЕЁо1.с 


1 116 1зсоппесееЯ( 5ОскЕТ з, ЕЯ_зеЕ *уа, ЕЯ_зее *иг, ЕЯ_зеё *ех }) 
й{ 

3 ИзЗАбееГазЕЕггог (0 }; 

4 1Е ( !РО_Т55$ЕТ( в, га ) && !РО_Т55ЕТ( в, мг ) ) 

5 гебаги 0; 

6 1Е ( РО_Т55ЕТ( зв, ех )} ) 

7 гебогп 0; 

8 гесогп 1; 

9 } 


соппесёёЁо1.с 


3-> — Так же, как и в версии для ОМХ, проверяем, соединен ли сокет. Если 
нет, устанавливаем последнюю ошибку в нуль и возвращаем нуль. 

6-8 Если для сокета есть событие исключения, возвращается нуль, в про- 
тивном случае - единица. 


Резюме 


Как видите, для переноса на разные платформы прерывать вызов соппес® 
с помощью тайм-аута более сложно, чем обычно. Поэтому при выполнении такого 
действия надо уделить особое внимание платформе. 

Наконец, следует понимать, что сократить время ожидания соппесе можно, 
а увеличить - нет. Все вышерассмотренные методы направлены на то, чтобы пре- 
рвать вызов соппесё раньше, чем это сделает ТСР. Не существует переносимого 
механизма для изменения значения тайм-аута ТСР на уровне одного сокета. 


Совет 26. Избегайте копирования данных 


Во многих сетевых приложениях, занимающихся, прежде всего, переносом дан- 
ных между машинами, болыная часть времени процессора уходит на копирование 
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данных из одного буфера в другой. В этом разделе будет рассмотрено несколько 
способов уменьшения объема копирования, что позволит «бесплатно» повысить 
производительность приложения. Предложение избегать копирования больших 
объемов данных в памяти оказывается не таким революционным, поскольку имен- 
но так всегда и происходит. Массивы передаются не целиком, используются толь- 
ко указатели на них. 

Конечно, обычно данные между функциями, работающими внутри одного про- 
цесса, не копируются. Но в многопроцессных приложениях часто приходится пе- 
редавать большие объемы данных от одного процесса другому с помощью того или 
иного механизма межпроцессного взаимодействия. И даже в рамках одного про- 
цесса часто доводится заниматься копированием, если сообщение состоит более 
чем из двух частей, которые нужно объединить перед отправкой другому процессу 
или другой машине, Типичный пример такого рода, обсуждавшийся в совете 24, — 
это добавление заголовка в начало сообщения. Сначала копируется в буфер заго- 
ЛОВОК, а вслед за НИМ - само сообщение. 

Стремление избегать копирования данных внутри одного процесса — признак 
хорошего стиля программирования. Если заранее известно, что сообщению будет 
предшествовать заголовок, то надо оставить для него место в буфере. Иными сло- 
вами, если ожидается заголовок, описываемый структурой зЕгисе пах, то прочи- 
тать данные можно было бы так: 


гс = геа@( Еа, БаЕЁ + з12еоЁ( зЕехасЕ Вах ) ), 
312еоЁ( БаЁ ) - з17еоЁ( зЕегасе Вах ); 


Пример применения такой техники содержится в листинге 3.6. 

Еще один прием - определить пакет сообщения в виде структуры, одним из 
элементов которой является заголовок. Тогда можно просто прочитать заголовок 
в одном из полей: 


зЕГАСЕ { 
зЕкгисЕ Наг Веааег; /* Структура определена в другом месте. */ 
спаг Яаба[ РАТАЗ2 ]; 

} раскее; 

гс = геаЯ( ЕЯ, расКеЕ, даба. з12еоЁ( расКеЕ даба ) ); 


Пример использования этого способа был продемонстрирован в листинге 2.15. 
Там же говорилось, что при определении такой структуры следует проявлять 
осмотрительность. 

Третий, очень гибкий, прием заключается в применении операции записи со 
сбором -— листинги 3.23 (МХ) и 3.24 (\УМпзосК). Он позволяет объединять части 
сообщения с различными размерами. 

Избежать копирования данных намного труднее, когда есть несколько процессов. 
Эта проблема часто возникает в системе О МХ, где многопроцессные приложения — 
распространенная парадигма (рис. 3.4). Обычно в этой ситуации проблема даже ост- 
рее, так как механизмы ГРС, как правило, копируют данные отправляющего процесса 
в пространство ядра, а затем из ядра в пространство принимающего процесса, то есть 
копирование происходит дважды. Поэтому необходимо применять хотя бы один из 
вышеупомянутых методов, чтобы избежать лишних операций копирования. 
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Буферы в разделяемой памяти 


Обойтись почти без копирования, даже между разными процессами, можно, вос- 
пользовавшись разделяемой памятью. Разделяемая память — это область памяти, до- 
ступная сразу нескольким процессам. Каждый процесс отображает блок виртуальной 
памяти на адрес в собственном адресном пространстве (в разных процессах эти адреса 
могут быть различны), а затем обращается к нему, как к собственной памяти. 

Идея состоит в том, чтобы создать массив буферов в разделяемой памяти, 
построить сообщение в одном из них, а затем передать индекс буфера следующе- 
му процессу, применяя механизм [РС. При этом «перемещается» только одно це- 
лое число, представляющее индекс буфера в массиве. Например, на рис. 3.15 в ка- 
честве механизма [РС используется ТСР для передачи числа 3 от процесса 1 
процессу 2. Когда процесс 2 получает это число, он определяет, что приготовлены 
данные в буфере эпьаггау [3 ]. 


Процесс 1 


Формирование 
сообщения 


этпраггау [3] 


а и Получение 
сообщения 


ТСР-соединение 


Рис. 3.15. Передача сообщений через буфер в разделяемой памяти 


На рис. 3.15 два пунктирных прямоугольника представляют адресные простран- 
ства процессов 1 и 2, а их пересечение — общий сегмент разделяемой памяти, кото- 
рый каждый из процессов отобразил на собственное адресное пространство. Массив 
буферов находится в разделяемом сегменте и доступен обоим процессам. Процесс 1 
использует отдельный канал [РС (в данном случае — ТСР) для информирования про- 
цесса 2 о том, что для него готовы данные, а также место, где их искать. 

Хотя здесь показано только два процесса, этот прием прекрасно работает для 
любого их количества. Кроме того, процесс 2, в свою очередь, может передать со- 
общение процессу 1, получив буфер в разделяемой памяти, построив в нем сооб- 
щение и послав процессу 1 индекс буфера в массиве. 
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Единственное, что пока отсутствует, — это синхронизация доступа к буферам, 
то есть предотвращение ситуации, когда два процесса одновременно получат один 
и тот же буфер. Это легко делается с помощью мьютекса, что и будет продемонст- 
рировано ниже. 


Система буферов в разделяемой памяти 


Описанную систему буферов в разделяемой памяти легко реализовать. Основ- 
ная сложность в том, как получить область разделяемой памяти, отобразить ее на 
собственное адресное пространство и синхронизировать доступ к буферам. Конеч- 
но, это зависит от конкретной системы, поэтому далее будет приведена реализа- 
ция как для ОХ, так и для МЯпдо\. 

Но прежде чем перейти к системно-зависимым частям, обратимся к АРГ и его 
реализации. На пользовательском уровне система состоит из пяти функций: 


и Ро Е ВЕ ИЕ ав | 


#2пс1аае "ебср.В" 

У01а 1п16_зпЪ( 116 1101Е_Ёгее]115); 

уо1А *зтЬа11ос( уо1а ); 

Возвращаемое значение: указатель на буфер в разделяемой памяти. 
уо1А эпЬЕгее( уо1а *эзтЬрЕг ); 

уо1А эпзепа( 5ОСКЕТ 5, уо1а * эпЬрЕЁг ); 

уо1А *зпЬгесу( 5ОСКЕТ $ ); 


Возвращаемое значение: указатель на буфер в разделяемой памяти. 


ыыы ты ыыы === ы- 


Перед тем как пользоваться системой, каждый процесс должен вызвать 
функцию 111% зи для получения и инициализации области разделяемой па- 
мяти и синхронизирующего мьютекса. При этом только один процесс должен 
вызвать 1116 _эпЪ с параметром 1п11*_ЁЕгее115®, равным ТВОЕ. 

Для получения буфера в разделяемой памяти служит функция эпЬа11ос, воз- 
вращающая указатель на только что выделенный буфер. Когда буфер уже не ну- 
жен, процесс может вернуть его системе с помощью функции эп _Егее. 

Построив сообщение в буфере разделяемой памяти, процесс может передать 
буфер другому процессу, вызвав эпЬзепа. Как уже говорилось, при этом передается 
только индекс буфера в массиве. Для получения буфера от отправителя процесс- 
получатель вызывает функцию зиогесу, которая возвращает указатель на буфер. 

В данной системе для передачи индексов буферов используется ТСР в каче- 
стве механизма [РС, но это не единственное и даже не оптимальное решение. Так 
удобнее, поскольку этот механизм работает как под ОМЁХ, так и под УЙп4о\з, 
иктому же можно воспользоваться уже имеющимися средствами, а не изучать дру- 
гие методы ГРС. В системе ОМХ можно было бы применить также сокеты в адрес- 
ном домене ОМХ или именованные каналы. В \УЛп4о\з доступны бепаМеззасде, 
Оцеце/зекАРС и именованные каналы. 

Начнем рассмотрение реализации с функций эпБа11ос и зпЪЕгее (листинг 3.28). 
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Листинг 3.28. Функции зэтрайос и зтЬКее 


т.с 


1 #1пс1аае "ебср.В" 
2 #+аеЕ1ре ЕВЕЕ_ГТ5Т зпраггау[ М$УМВ ].пехё1 
3 суреаеЕЁ ип1оп 
4 { 
5 лиЕ пехЕ1; 
6 сраг БоЕ[ $МВУЕ$57 ]; 
7 } эиЬ_Е; 
8 эспЬ_ Е *зифаггау; 
9 уо1а *зпра11ос( уо1а ) 
10 { 
11 зпь_Е *Ьр; 
12 1оск_БаЕЁ(); 
13 1Е ( ЕРВЕЕ_ПЦТУТ < 0} 
14 еггог( 1, 0, "больше нет буферов в разделяемой памяти\п" ); 
15 Ър = эираггкау + ЕВЕЕ_БТ5Т; 
16 ЕВЕЕ_ГТЗТ = Бр->пехЕ1; 
17 цп1оск_БаЁ(); 
18 гебагп Бр; 
19 
20 уо1а зпирЁгее ( уо1а *Ъ } 
И: 
22 эп _Е *Ьр; 
РЕ Бр = Ь; 
24 1оск_БоЕЁ(); 
25 Бр->пехЕ1 = ЕВЕЕ_ГТУТ; 
26 ЕВЕЕ_ЁЬТЗТ = Бр - эпаггкау; 
27 ип1оск_БаЕЁ(); 
28 } 
зтр.с 
Заголовок 
2-8 — Доступные буфера хранятся в списке свободных. При этом в первых 


$12еоЕ ( 106 ) байтах буфера хранится индекс следующего свободно- 
го буфера. Такая организация памяти отражена в объединении эп _Е. 
В конце массива буферов есть одно целое число, которое содержит либо 
индекс первого буфера в списке свободных, либо —1, если этот список 
пуст. Доступ к этому числу вы получаете, адресуя его как зпраггау 
[ М5МВ ].пехЕ1. Для удобства это выражение инкапсулировано в мак- 
рос ЕВЕЕ_ГТ5Т. Насам массив буферов указывает переменная эпфаггау. 
Это, по сути, указатель на область разделяемой памяти, которую каж- 
дый процесс отображает на свое адресное пространство. В массиве ис- 
пользованы индексы, а не адреса элементов, так как в разных процес- 
сах эти адреса могут быть различны. 
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зтрайЙос 

12 Вызываем функцию 1оск_раЕ, чтобы другой процесс не мог обратить- 
ся к списку свободных. Реализация этой функции зависит от системы. 
В ОМХ будут использованы семафоры, а в \УЛп4о\$ — мьютексы. 

13-16 Получаем буфер из списка свободных. Если больше буферов нет, то 
выводим диагностическое сообщение и завершаем сеанс. Вместо этого 
можно было бы вернуть МОТ... 

17-18 Открываем доступ к списку свободных и возвращаем указатель на 
буфер. 

зтЬее 


23-27 После блокировки списка свободных, возвращаем буфер, помещая его 
индекс в начало списка. Затем разблокируем список свободных и воз- 
вращаем управление. 


Далее рассмотрим функции зпирзепа и зиргесу (листинг 3.29). Они посыла- 
ют и принимают целочисленный индекс буфера, которым обмениваются процес- 
сы. Эти функции несложно адаптировать под иной механизм межпроцессного вза- 
имодействия. 


Листинг 3.29. Функции зтЬзепа и зтЬгесу 


втр.с 

1 уозла зпбзера( 5ОСКЕТ з, уо1а *Ь ) 

й-[ 

Е 1пЕ 1паех; 

4 1паех = ( зи 6 * )Ь - зэзибаггау; 

5 1Е ( зепа( <, ( саг * )&1паех, з1хеоЁ( 1паех }, 0) <0) 
6 еггог( 1, еггпо, "эпбзеп@а: ошибка вызова зепа" ); 

7} 

8 уо1а *зшргесу( бОСКЕТ $ ) 

8 

10 106 1п4ех; 

11 116 гс; 

12 гс = геадп( з, ( срак * )&1паех, з1хеоЕЁ( 1паех )} ); 

13 1Е (гс == 0) 

14 ехгог( 1, 0, "эзпфгесу: другой конец отсоединился\п" ); 
15 е1зе 1Е ( гс != вс1хеоЕЁ( 1паех ) ) 

16 еггог( 1, еггпо, "зпфгесу: ошибка вызова геаап" )}; 

ти гебигп зпБаггау + 1паех; 

18 } 

этр.с 

5ть5епа 
4-6 Вычисляем индекс буфера, на который указывает Ь, и посылаем его 


другому процессу с помощью зепа. 


РВ ВВ ВИА ВИ ВИ — Создание эффективных сетевых программ 


5тьгесу 


12-16 Вызываем геадп для чтения переданного индекса буфера. В случае 
ошибки чтения или при получении неожиданного числа байт, выводим 
сообщение и завершаем работу. 

17 В противном случае преобразуем индекс буфера в указатель на него 
и возвращаем этот указатель вызывающей программе. 


Реализация в ИМХ 


Для завершения реализации системы буферов в разделяемой памяти нужны 
еще два компонента. Это способ выделения блока разделяемой памяти и отобра- 
жения его на адресное пространство процесса, а также механизм синхронизации 
для предотвращения одновременного доступа к списку свободных. Для работы 
с разделяемой памятью следует воспользоваться механизмом, разработанным в 
свое время для версии 5у5У. Можно было бы вместо него применить отображенный 
на память файл, как в \УЛп4о\з. Кроме того, есть еще разделяемая память в стан- 
дарте РОЗИХ - для систем, которые ее поддерживают. 

Для работы с разделяемой памятью Зу5\У понадобятся только два системных 
вызова : 


#1пс1аае <зуз/зЬа.В> 


106 эзридее( Кеу_6 Кеу, з1хе_6 512е, 116 ЕЁ]1ад$ }; 


Возвращаемое значение: идентификатор сегмента разделяемой памяти в слу- 
чае успеха, —1 — в случае ошибки. 


\У01Я эзПмаф( 116 5ед91А, сопзЕ у\о1а *Базеаааг, 116 Е1адз )}; 


Возвращаемое значение: базовый адрес сегмента в случае успеха, —1 - в слу- 
чае ошибки. 


Системный вызов зНадеЕ применяется для выделения сегмента разделяемой 
памяти. Первый параметр, Кеу, — это глобальный для всей системы уникальный 
идентификатор, сегмента. Сегмент будет идентифицироваться целым числом, пред- 
ставление которого в коде АЗСИ равно ЗМВМ. 


Примечание Использование пространства имен, отличного от файловой си- 
стемы, считается одним из основных недостатков механизмов 
]РС, появившихся еще в системе 5у5У. Для отображения имени 
файла на ключ 1РС можно применить функцию ЕЕОК, но это 
отображение не будет уникальным. Кроме того, как отмечает- 
ся в книге [5%е0еп5 1999], описанная в стандарте 5УКА4 функция 
ЕБоК дает коллизию (то есть два имени файла отображаются 
на один и тот же ключ) с вероятностью 72%. 


Параметр з12е задает размер сегмента в байтах. Во многих ОМХ-системах 
его значение округляется до величины, кратной размеру страницы. Параметр 
ЁЕ1адз задает права доступа и другие атрибуты сегмента. Значения $НМ_В и $НМ_М 
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определяют соответственно права на чтение и на запись для владельца. Права для 
группы и для всех получают путем сдвига этих значений вправо на три (для груп- 
пы) или шесть (для всех) бит. Иными словами, право на запись для группы -— это 
$НМ_М >> 3, а право на чтение для всех — $НМ_В >> 6. Когда в параметр Ё1а9$ 
с помощью побитовой операции ОК включается флаг ТРС_СВЕАТЕ, создается сег- 
мент, если раньше его не было. При дополнительном включении флага ТРС_ЕХСЬ 
зридее вернет код ошибки ЕЕХТЕТ, если сегмент уже существует. 

Вызов зНиаее только создает сегмент в разделяемой памяти. Для отображения 
его в адресное пространство процесса нужно вызвать зрла®. Параметр 5е914 - это 
идентификатор сегмента, который вернул вызов эзриде*е. При желании можно ука- 
зать адрес Базеаааг, на который ядро должно отобразить сегмент, но обычно этот 
параметр оставляют равным МОБ, позволяя ядру самостоятельно выбрать адрес. 
Параметр Ё1ад$ используется, если значение Базеааах не равно МОГ, — он управ- 
ляет выравниваем заданного адреса на приемлемую для ядра границу. 

Для построения механизма взаимного исключения следует воспользоваться 
ЗузУ-семафорами. Хотя они небезупречны (в частности, им присуща та же про- 
блема нового пространства имен, что и разделяемой памяти), Зу$У-семафоры ши- 
роко используются в современных ОМХ-системах и, следовательно, обеспечивают 
максимальную переносимость. Как и в случае разделяемой памяти, сначала надо по- 
лучить и инициализировать семафор, а потом уже его применять. В данной ситу- 
ации понадобятся три относящихся к семафорам системных вызова. 

Вызов зешдее аналогичен зридее: он получает у операционной системы 
семафор и возвращает его идентификатор. Параметр ХКеу имеет тот же смысл, 
что и для эридее — он именует семафор. В ЗузУ-семафоры выделяются группами, 
и параметр пзетз означает, сколько семафоров должно быть в запрашиваемой 
группе. Параметр Ё1ад$ такой же, как для эВ тае*. 


#10с1а9е <зуз/зет. > 


106 земаебе( Кеу_6 Кеу, 116 пзет$, 11 Е1ад9$ ); 


Возвращаемое значение: идентификатор семафора в случае успеха, —1 - в слу- 
чае ошибки. 


106 земсё1( 116 зет1Я, 116 зетпит, 1пе ста, ... ); 


Возвращаемое значение: неотрицательное число в случае успеха, -1 - в слу- 
чае ошибки. 


106 зетор( 116 зеп1Я, зегасе зетраЁ *ораггау, в12е_6 пор$ ); 


Возвращаемое значение: 0 в случае успеха, —1 - в случае ошибки. 


Здесь использована зетс®1 для задания начального значения семафора. Этот 
вызов служит также для установки и получения различных управляющих пара- 
метров, связанных с семафором. Параметр зет1а - это идентификатор семафора, 
возвращенный вызовом зепдее. Параметр зелпит означает конкретный семафор 
из группы. Поскольку будет выделяться только один семафор, значение этого па- 
раметра всегда равно нулю. Параметр ста — это код выполняемой операции. 


РЯ: № ВОНИ ВИНЫ = Создание эффективных сетевых программ 


У вызова зешдее могут быть и дополнительные параметры, о чем свидетельству- 
ет многоточие в прототипе. 

Вызов зетор используется для увеличения или уменьшения значения сема- 
фора. Когда процесс пытается уменьшить семафор до отрицательного значения, 
он переводится в состояние ожидания, пока другой процесс не увеличит семафор 
до значения, большего или равного тому, на которое первый процесс пытался его 
уменьшить. Поскольку надо использовать семафоры в качестве мьютексов, сле- 
дует уменьшать значение на единицу для блокировки списка свободных и увели- 
чивать на единицу — для разблокировки. Так как начальное значение семафора 
равно единице, в результате процесс, пытающийся заблокировать уже блокирован- 
ный список свободных, будет приостановлен. 

Параметр веп1Аа- это идентификатор семафора, возвращенный зепдае*. Па- 
раметр ораггау указывает на массив структур зетБиЕЁ, в котором заданы опера- 
ции над одним или несколькими семафорами из группы. Параметр порз задает 
число элементов в массиве ораггау. 

Показанная ниже структура зетриЕ содержит информацию о том, к какому 
семафору применить операцию (зеп_поам), увеличить или уменьшить значение 
семафора (зеп_ор), а также флаг для двух специальных действий (зеп_Ё19): 


зЕгисЕ зетшбаЕ { 


ц_зрогЕ зеш_ пам; /* Номер семафора. */ 
зВогЕ зеп_ор; /* Операция над семафором. */ 
зВогЕ зем_ЁЕ1а; /* Флаги операций. */ 


К: 


В поле зет_Ё1а могут быть подняты два бита флагов: 


О ТРС_МОМАТТ - означает, что зетор должна вернуть код ЕАСАТМ, а не приоста- 
навливать процесс, если в результате операции значение семафора окажется 
отрицательным; 

О ЗЕМ_ОМОО - означает, что зетор должна отменить действие всех операций над 
семафором, если процесс завершается, то есть мьютекс будет освобожден. 


Теперь рассмотрим ОМХ-зависимую часть кода системы буферов в разделяе- 
мой памяти (листинг 3.30). 


Листинг 3.30. Функция тй_зтЬ для ИМХ 


этЬ.с 


#1ос1аае <зуз/збт.В> 

#1п0с1аае <зуз/зею.Н> 

#АеЕ1пе МОТЕХ_КЕУ 0х534а4253 /* 5МВ$ */ 

#аеЕ1пе $М_КЕУ 0х534а424а /* ЭМВМ */ 

#ЧеЕ1пе 1осКк_роаЁ() 1ЕЁЕ ( зетор( мобех, &1КБаЕ, 1) < 0) \ 
еггог( 1, еггпо, "ошибка вызова зептор" ) 

#АеЕ1пе пр1оск_раЁ() 1Е ( земор( мабех, &оп1КБаЕ, 1) < 0) \ 
еггохг( 1, еггро, "ошибка вызова зетор" ) 


оююФчмиялюошьн 


106 пабех; 
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10 зЕхосЕ зепраЁ 1КБаЕ; 
11 зЕкисЕ зейраЕ оп1КБоЕЁ; 


12 уо1а 101Е_эмЬ( 116 1116 _Егее115е } 


13 { 

14 иптоп зетоп ага; 
15 116 зп1а; 

16 ТЕ т 

17 1р6 кс; 


18 1КБаЁ.зеп_ор = -1; 

19 1КРаЁ.зеп_Ё1а = $5ЕМ_9М№ОО; 

20 171КриЕ.зем_ор = 1; 

21 ип1КриЕ. вем_Ё1а9 = ЗЕМ_ОМОО; 
22 писех = зетаее( МИОТЕХ_КЕУ, 1, 


23 ТРС_ЕХСЬ | ТРС_СВЕАТ | 5ЕМ_В | $5ЕМА )}; 

24 1Е ( мабех >= 0 ) 

25 { 

26 ага.\а1 = 1; 

27 гс = зетсё1( пабех, 0, ЗЕТУАГ, ака ); 

28 1Е (тс < 0) 

29 егхог( 1, ехкпо, "зетсЕе1 Еа11е@" ); 

30 } 

31 е1зе 1Ё ( ехкпо == ЕЕХТЯТ } 

32 { 

33 пибех = земаеё( МОТЕХ_КЕУ, 1, 5ЕМ_В | 5ЕМА }; 
34 1Е ( пысех < 0) 

35 еггог( 1, еггро, "ошибка вызова зепсЕ1"“ }; 
36 } 

37 е1зе 

38 ехгог( 1, екгпо, "ошибка вызова зетсЕ1“ ); 


39 $01 = зБтаее( $М_КЕУ, ММВ * з1хеоЁ{( эзпЪ_Е } + э1хеоЁ{( 106 ), 


40 ЭНМ_В | $5НМ И [ ТРС_СВЕАТ ); 

41 1Е ( зи1а < 0} 

42 еггог( 1, еххпо, "ошибка вызова зЮидее" }; 
43 зпракгау = ({ эзир_6 * )зртабе( эта, мо, 0); 
44 1Е ( эпБагкгау == ( уо1а * }-1 } 

45 еггок( 1, екгпо, "ошибка вызова зПмае" ); 
46 1ЁЕ ( 1016_Ехее1156 ) 

47 { 

48 Бог (1= 0; 1 < ММВ - 1; 1++ } 

49 эзпраггау[ 1 ].пехё1 = 1 + 1; 

50 эпраггау[ ММВ - 1 ].пехЕ1 = -1; 

51 РВЕЕ_ГТОТ = 0; 

52 } 

53 } 


т.с 


РЕЗ ШИ ИИИ В — Создание эффективных сетевых программ 


Макросы и г. лобальные переменные 


3-4 
5-8 


9-11 


Определяем ключи сегмента разделяемой памяти (5МВМ) и семафо- 
ра (5МВ5). 

Определяем примитивы блокировки и разблокировки в терминах опе- 
раций над семафорами. 

Объявляем переменные для семафоров, используемых для реализации 
мьютекса. 


Получение и инициализация семафора 


18-21 


22-38 


Инициализируем операции над семафорами, которыми будем пользо- 
ваться для блокировки и разблокировки списка свободных. 

Этот код создает и инициализирует семафор. Вызываем зетаее с фла- 
гами ТРС_ЕХСГ и ТРС_СВЕЛАТ. В результате семафор будет создан, если 
он еще не существует, и в этом случае зетаее вернет идентификатор 
семафора, который инициализируем единицей (разблокированное со- 
стояние). Если же семафор уже есть, то снова вызываем зетдее, уже 
не задавая флагов ТРС_ЕХСЦ и ТРС_СВЕАТ, для получения идентифи- 
катора этого семафора. Как отмечено в книге [З{еуепз$ 1999], теорети- 
чески здесь возможна гонка, но не в данном случае, поскольку сервер 
вызывает 1п1=_эпЪ перед вызовом 11з5еп, а клиент не сможет обра- 
титься к нему, пока вызов соппесе не вернет управление. 


Примечание В книге [51е%еп; 1999] рассматриваются условия, при которых 


возможна гонка, и показывается, как ее избежать. 


Получение, отображение и инициализация буферов в разделяемой памяти 
39-45 Выделяем сегмент разделяемой памяти и отображаем его на свое ад- 


46-53 


ресное пространство. Если сегмент уже существует, то зВидеЕ возвра- 
щает его идентификатор. 

Если 1116 _эпЪ была вызвана с параметром 111Е_Ёгее115, равным 
ТВОЕ, то помещаем все выделенные буферы в список свободных и воз- 
вращаем управление. 


Реализация в И/паои/б 


Прежде чем демонстрировать систему в действии, рассмотрим реализацию 
для УЛп4о\з. Как было упомянуто выше, весь системно-зависимый код сосредо- 
точен в функции 1116 _зпЪ. В УЛп4о\з мьютекс создается очень просто — доста- 
точно вызвать функцию СгеакеМакех. 


#1пс1аае <и1пд9омз.Н> 


НАМОЬЕ СгеабсеМакех ( .РЗЕСОВТТУ_АТТВЕТВОТЕС 1]рза, 


ВОО ЁГ1п1ё1а1Оипехг, ПРТЗТВ 1рз2МиЕехМапте ); 


Возвращаемое значение: описание мьютекса в случае успеха, МОТ, — в случае 
ошибки, 
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Параметр 1рза - это указатель на структуру с атрибутами защиты. Здесь эта 
возможность не нужна, так что вместо этого аргумента передадим МОГ1.. Параметр 
ЕТп1Е1а1Оипег означает, будет ли создатель мьютекса его начальным владель- 
цем, то есть следует ли сразу заблокировать мьютекс. Параметр 1рз=МиЕехМапе -— 
это имя мьютекса, по которому к нему могут обратиться другие процессы. Если 
мьютекс уже существует, то СкеабеМисех просто вернет его описание. 

Блокировка и разблокировка мьютекса выполняются соответственно с помо- 
щью функций ИМа1Рог51п191е0Ъ3) есё и Ве1еазеМисех. 


#10с1аае <илпаомз.Н> 


ОИОВКО Ма1еЕРЕог$1па1е0Ъ)есе( НАМРЬЕ ВОБ]есе, ПОМОВО @мТ1меоце ); 


Возвращаемое значение: МАТТ_ОВОЕСТ_0 (0) в случае успеха, ненулевое зна- 
чение - в случае ошибки. 


ВООГ Ве1еазеМмиеех( НАМОГЕ РМиеех ); 


Возвращаемое значение: ТВОЕ в случае успеха, ГАГЗЕ - в случае ошибки. 


Параметр ВОБ7есЕ функции Иа1Рог51п91е0Ъ5)ес® - это описание ожидаемо- 
го объекта (в данном случае мьютекса). Если объект, заданный с помощью РОБ7есь, 
не занят (319та1еа), то Ма\ЕРГог51п91е0Ъ)ес® занимает его и возвращает управ- 
ление. Если же объект занят (по{ 31ачпа1еа), то обратившийся поток переводит- 
ся в состояние ожидания до тех пор, пока объект не освободится. После этого 
Ма1 Рог51п91е0Ъ)есЕ переведет объект в занятое состояние и вернет в работу 
«спящий» поток. Параметр амГ1теоиЕ задает время (в миллисекундах), в течение 
которого потоком ожидается освобождение объекта. Если тайм-аут истечет прежде, 
чем объект освободится, то Иа1ЕЕог51п91е0Ъ)есЕ вернет код МАТТ ТТМЕООТ. Тай- 
мер можно подавить, задав в качестве амиГттеоиЕ значение ТМЕТМТТЕ. 

Когда поток заканчивает работу с критической областью, охраняемой мьютек- 
сом, он разблокирует его вызовом Ве1еазеМисех, передавая описание мьютекса 
НМиесех в качестве параметра. 

В УЛп4о\з вы получаете сегмент разделяемой памяти, отображая файл на па- 
мять каждого процесса, которому нужен доступ к разделяемой памяти (в УМХ 
есть аналогичный системный вызов пар). Для этого сначала создается обычный 
файл с помощью функции СгеасеР11е, затем — отображение файла посредством 
вызова СгеакеЕ1 1еМарр1п9а, а уже потом оно отображается на ваше адресное про- 
странство вызовом МарУ1емОЕЕ11е. 

Параметр ВЕ: 1е в вызове СгеакеЕ11еМарр1па — это описание отображаемого 
файла. Параметр 1рза указывает на структуру с атрибутами безопасности, которые 
в данном случае не нужны. Параметр ЕаиРгоЕесЕ определяет права доступа к объек- 
ту в памяти. Он может принимать значения РАСЕ_ВЕАРОМГУ, РАСЕ_ВЕАРИВТТЕ или 
РАСЕ_МВТТЕСОРУ. Последнее значение заставляет ядро сделать отдельную копию 
данных, если процесс пытается записывать в страницу памяти. Здесь используется 
РАСЕ_ВЕАРМВТТЕ, так как будет производится и чтение, и запись в разделяемую 
память. Существуют также дополнительные флаги, объединяемые операцией 
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побитового ОК, которые служат для управления кэшированием страниц памяти, 
но они не понадобятся. Параметры ЯмиМах1тит51 веН1аН и аийМах1тит512еГовв со- 
вокупности дают 64-разрядный размер объекта в памяти. Параметр 1р5=МарМапте - 
это имя объекта. Под данным именем объект известен другим процессам. 


#1пс1аае <и1иЯомз. [> 


НАМОЬЕ СгеаЕеРг11еМарр1па( НАМОГЕ №Р11е, ГРЗЕСИВТТУ_АТТЕТВОТЕ$ 1рёа, 
ОМИОВО ЕаиРгоЕесЕ, ПМОВО аиМах1тит512хен1оар, 
ОМОВР АЧиМах1тит5$1гегои, ПРУТВ 1рэз2МарМате ); 


Возвращаемое значение: описатель отображения файла в случае успеха, МОТ, — 
в случае ошибки. 


ТГРУОТР МарУ1емОЕЕР11е( НАМОГЕ №Е1]еМарОБуесЕ, ПМОКО амр)ез1геаАссезз, 
ОМОВО @амЕ11е0ЕЁЕзеЕН1ай, ОМОКО амЕ11е0ЕЕзеЕГом, 
ОМОВр амВуЕезТоМар }; 


Возвращаемое значение: адрес, на который отображена память, в случае успе- 
ха, МОТ — в случае ошибки. 


После создания объект в памяти отображается на адресное пространство каж- 
дого процесса с помощью функции МарУ1емОЕЕ11е. Параметр РЕ11еМароБ} - это 
описание, возвращенное после вызова СтеакеЁР11еМарр1па. Требуемый уровень 
доступа следует задать с помощью ам)ез1геаАссезе. Этот параметр может при- 
нимать следующие значения: ЕТГЕ_МАР_МВТТЕ (доступ на чтение и запись), 
РТЬЕ_МАР_ВЕАГ (доступ только на чтение), ЕТЬЕ_МАР_АГТ,_АССЕУ$ (то же, что 
ЕТЬЕ_МАР_МВТТЕ) и ЕТЬЕ_МАР_СОРУ. Если присвоено последнее значение, то при 
попытке записи создается отдельная копия данных. Параметры ЯмЕ11е0ЕЁ5еЕН1о0й 
И 9иР11е0ЕЕзееГом задают смещение от начала файла, с которого следует начи- 
нать отображение. Нужно отобразить файл целиком, поэтому оба параметра будут 
равны 0. Размер отображаемой области памяти задается с помощью параметра 
ЯиВуЕезТоМар. 

Подробнее использование мьютексов и отображение памяти в УЛп4о\з рас- 
сматриваются в книге [ КзсЩег 1997]. 

Теперь можно представить версию 1116 _епЪ для УЛидо\з. Как видно из лис- 
тинга 3.31, она очень напоминает версию для ОШМХ. 


Листинг 3.31. Функция тй_зтЬ для ИИп4ом/$ 


втр.с 


#ЧеЕ1пе ЕТЬЕМАМЕ "./зтрЕ11е" 
#аеЕ1пе 1оск_ЬаЕЁ() 1Е ( Ма1еРог$1па1е0Ь]есе( шабех, ТМЕТМТТЕ )\ 
|= МАТТ_ОВУЕСТ_0 ) \ 

еггог( 1, егкпо, "ошибка вызова 1оск_БаЕ " ) 
#аеЁ1пе чп1оскК_БаЕЁ() 1Е ( 'Ве1еаземиеех( пабех ) )\ 

еггог( 1, еггпо, "ошибка вызова ип1оск_ЮаЁ" ) 
НАМОЬБЕ пабех; 
уо1А 1101505 ( 1106 11016 _Егее1156 ) 


очи ююьн 
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ты 

10 НАМОЬЕ ВЕ11е; 
11 НАМРЬЕ Бмар; 
12 10 1; 


13 писех = СгеасеМисех( МОГ, КАГЗЕ, "зпртшисех” ); 
14 1Е ( пыбех == МОМ, ) 


15 еггох( 1, егхпо, "ошибка вызова СгеабеМиебех" }; 

16 ВЕ11е = СгеабсеЕ11е( ЕТЬЕМАМЕ, 

17 СЕМЕВТС_ВЕАР | СЕМЕВТС_МВТТЕ, 

18 ЕТЬЕ_ЗНАВЕ_ВЕАР | ЕТЬЕ_СНАВЕ_ МВТТЕ, 

19 МОГ, ОРЕМ_АГМАУ$, ЕТЬЕ_АТТВЬТВОТЕ_МОВМАЬ, МОШ ); 

20 1Е ( №Е11е == ТМУАЬБТО_НАМОБЕ_УАЦОЕ ) 

21 еггог( 1, еггпо, "ошибка вызова СгеафеЕ11е" ); 

22 Пиар = Сгеабег11еМарр1па( №Ё11е, МОШМ,, РАСЕ_ВЕАРМВТТЕ, 

23 0, М5МВ * в17еоЁ( зп _Е ) + 512еоЁ( 106 ), "зибаггау" }; 


24 эпрахгау = Мар\У1емОЕЕ11е( Пиар, ЕТЬЕ_МАР_МВТТЕ, 0, 0, 0); 
25 1Е ( эпраккау == МОШ  ) 


26 еггог( 1, еггпо, "ошибка вызова Мар\/1емОЕЕ11е" ); 
27 

28 1Е ( 11016_ЁЕгее115% ) 

29 { 

30 Бог (1=0; 1 < М5МВ - 1; 1++ } 

31 эзиБаггау[ 1 ]|].пехё1 = 1 + 1; 

За зпраггау[ М$МВ - 1 ].пехЕё1 = -1; 

33 ЕВЕЕ_ГТОТ = 0; 

34 } 

35 } 


зтЬ.с 


Для тестирования всей системы следует написать небольшие программы кли- 
ентской (листинг 3.32) и серверной (листинг 3.33) частей. 


Листинг 3.32. Клиент, использующий систему буферов в разделяемой памяти 


этрс.с 
1 #1пс1аае "еЕср.Ь" 


2 1106 па1п( 106 агас, саг **ахгау } 


3 { 

4 спаг *Ьр; 

5 ЗОСКЕТ $5; 

6 ТМТтТ(); 

7 5 = Еср_<с11епё( агаду[ 1 |], агау[ 2 ] ); 

8 111Е_зпиЪ( ЕАБЗЕ ); 

9 Бр = зира11ос(); 

10 \01]е ( Едеё$( Бр, 5МВОЕ$7, збсалп ) != МмМОШЬ ) 
11 { 

12 эпиЬзепа ( $, Юр ); 


13 Бр = эпБа11ос(); 
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14 } 
15 ЕХТТ( 0); 
16 } 
зтрс.с 


Листинг 3.33. Сервер, использующий систему буферов в разделяемой памяти 


зтрз.с 
1 #1пс1аае "еёср.В" 
2 116 ма1п( 116 акас, спахг **агау } 
к: 
4 спаг *Ьр; 
5 ЗОСКЕТ 3; 
6 СОСКЕТ $51; 
7 ТМТТ(); 
8 1016_зпЪ( ТВОЕ ); 
9 3 = Еср_вегуег( М, агхау[ 1 ] }; 
10 81 = ассерё( з, МГ, М }; 
11 1Е ( 115%уа11ЯазосКкК( $1 ) ) 
12 еггог( 1, еггпо, "ошибка вызова ассере" ); 
13 Ро: о 9 
14 { 
15 Бр = зиргесу( 31 }; 
16 Ераб$( Бр, зЕаоце ); 
тв, зпрЁЕгее( Бр ); 
18 } 
19 ЕХТТ( О); 
20 } 
зтр5.с 
Запустив эти программы, получите ожидаемый результат: 
за: $ вшре 1оса1Вове 9000 ЪЬза: $ виьв 9000 
Не1]о Не11о 
Мокг1а! М\Мо1аз! 
^с зпрз: эпфркесу: другой конец отсоединился 
Ъза: $ Ьза: $ 


Обратите внимание, что эпЬс читает каждую строку из стандартного ввода 
прямо в буфер в разделяемой памяти, а зиЪз копирует каждую строку из буфера 
сразу на стандартный вывод, поэтому не возникает лишнего копирования данных. 


Резюме 


В этом разделе описано, как избежать ненужного копирования данных. Во 
многих сетевых приложениях на копирование данных из одного буфера в другой 
тратится большая часть времени процессора. 

Разработана схема взаимодействия между процессами, в которой используется 
система буферов в разделяемой памяти. Это позволило передавать единственный 
экземпляр данных от одного процесса другому. Такая схема работает и в ЧМХ, 
ив УМодо\у. 
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Совет 27. Обнуляйте структуру сосКаЧаг_т 


Хотя обычно используется только три поля из структуры зосКкааахг_1п: 
$1п_Еам1 Ту, $1п_рогё и $1п_аааЯгх, но, как правило, в ней есть и другие поля. На- 
пример, во многих реализациях есть поле 31п_1еп, содержащее длину структуры. 
В частности, оно присутствует в системах, производных от версии 4.3В$О КВепо 
и более поздних. Напротив, в спецификации \\пзоскК этого поля нет. 

Если сравнить структуры зосКаЯЯк_1п в системе ЕгееВ$О 


зЕгисЕ зоскКааагк_1п { 
\_сПахг в1п_1еп; 
ц_свах $1п_Еаш11у; 
и_спак$1п_роге; 
зЕГЦСЕ 1п_аЯаг э1п_аааг; 
спаг з1п_7его[8]; 


] 
ив М1 40\5 


эсгасЕ зоскаааг_ ап { 
эзрогё 81п_Ёаш11у; 
и_зВогЕ 911 рогкЕ; 
ЗЕГиСЕ 1п_аЧаг з1п_аааг; 
спах $1п_пегко[8); 


т: 


то видно, что в обеих структурах есть дополнительное поле $1п_2ехо. Хотя это 
поле и не используется (оно нужно для того, чтобы длина структуры зоскадах_1п 
была равна в точности 16 байт), но тем не менее должно быть заполнено нулями. 


Примечание Причина в том, что в некоторых реализациях во время привязки 
адреса к сокету производится двоичное сравнение этой адрес- 
ной структуры с адресами каждого интерфейса. Такой код бу- 
дет работать только в том случае, если поле в1п_гего запол- 
нено нулями. 


Поскольку в любом случае необходимо обнулить поле з1п_гего, обычно перед 
использованием адресной структуры ее полностью обнуляют. В этом случае заодно 
очищаются и все дополнительные поля, так что не будет проблем из-за недокумен- 
тированных полей. Посмотрите на листинг 2.3 — сначала в функции зе _аЯагезз 
делается вызов Ь2еко для очистки структуры зоскааахк_1п. 


Совет 28. Не забывайте о порядке байтов 


В современных компьютерах целые числа хранятся по-разному, в зависимости 
от архитектуры. Рассмотрим 32-разрядное число 305419896 (0х12345678). Четы- 
ре байта этого числа могут храниться двумя способами: сначала два старших байта 
(такой порядок называется тупоконечным — Ыя епд1ап) 


12 34 56 78 
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или сначала два младших байта (такой порядок называется остроконечным - 16 е 
еп ап) 


78 56 34 12 


Примечание Термины «тупоконечный» и «остроконечный» ввел Коэн [Сойеп 
1981], считавший, что споры о том, какой формат лучше, срод- 
ни распрям лилипутов из романа Свифта «Путешествия Гул- 
ливера», которые вели бесконечные войны, не сумев договорить- 
ся, с какого конца следует разбивать яйцо — с тупого или острого. 
Раньше были в ходу и другие форматы, но практически во всех 
современных машинах применяется либо тупоконечный, либо 
остроконечный порядок байтов. 


Определить формат, применяемый в конкретной машине, можно с помощью 
следующей текстовой программы, показывающей, как хранится число 0х12345678 
(листинг 3.34). 


Листинг 3.34. Программа для определения порядка байтов 


епа1ап.с 

1 #10пс1аае <з6@Я1о.1> 

2 #1пс1аае <зуз/бурез.Н> 

3 #1пс1аае "ебср.П" 

4 106 па1п( уола ) 

5 

6 м_1п632_6 х = 0х12345678; /* 305419896 */ 

7 \10$19пеЯ спаг *хр = ( сраг * )&х; 

9 рг1иЕЁ( "%0х %0х $0х %0х\п", 

10 ХЕ 0], ЖРЕТ 1; 521, ГЗ1 

11 ех1е (0); 

12 } 
епа1ап.с 


Если запустить эту программу на компьютере с процессором Ге], то получится: 


Ьза: $ епа1ап 
78 56 34 12 
Ьза: $ 


Отсюда ясно видно, это — остроконечная архитектура. 

Конкретный формат хранения иногда в шутку называют полом байтов. Он ва- 
жен, поскольку остроконечные и тупоконечные машины (а равно те, что исполь- 
зуют иной порядок) часто общаются друг с другом по протоколам ТСРИТР. По- 
скольку такая информация, как адреса отправления и назначения, номера портов, 
длина датаграмм, размеры окон и т.д., представляется в виде целых чисел, необхо- 
димо, чтобы обе стороны интерпретировали их одинаково. 

Чтобы обеспечить взаимодействие компьютеров с разными архитектурами, 
все целочисленные величины, относящиеся к протоколам, передаются в сетевом 
порядке байтов, который по определению является тупоконечным. По большей 
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части, обо всем заботятся сами протоколы, но сетевые адреса, номера портов, 
а иногда и другие данные, представленные в заголовках, вы задаете сами. И вся- 
кий раз необходимо преобразовывать их в сетевой порядок. 

Для этого служат две функции, занимающиеся преобразованием из машинно- 
го порядка байт в сетевой и обратно. Представленные ниже объявления этих функ- 
ций заимствованы из стандарта РОЗ1Х. В некоторых версиях ОМХ эти объявле- 
ния находятся не в файле пе 1пеё /1п.1. Типы у1п632_6 и 11616_6 приняты 
в РОЗ Х соответственно для беззнаковых 32- и 16-разрядных целых. В некоторых 
реализациях эти типы могут отсутствовать. Тем не менее функции Не оп] и пор] 
всегда принимают и возвращают беззнаковые 32-разрядные целые числа, будь то 
ОМХ или УЙпзосК. Точно так же функции Пеопз и пбойз всегда принимают 
и возвращают беззнаковые 16-разрядные целые. 


Примечание Буквы «1» и «5» в конце имен функций означают |опЕ (длинное) 
и рот: (короткое). Это имело смысл, так как первоначально дан- 
ные функции появились в системе 4.2850, разработанной для 
32-разрядной машины, где длинное целое принимали равным 
32 бит, а короткое - 16. С появлением 64-разрядных машин это 
уже не так важно, поэтому следует помнить, что [-функции ра- 
ботают с 32-разрядными числами, которые не обязательно пред- 
ставлены как [опё, а 5-функции - с 16 разрядными числами, кото- 
рые не обязательно представлены в виде зйоп. Удобно считать, 
что [-функции предназначены для преобразования длинных полей 
в заголовках протокола, а 5-функции — коротких полей. 


#$1пс1аае <пеб1птее/1т.6> /* ОМХ */ 
#10с1аае <м1озосКк2.1> /* УзпвосКк */ 


411632_Е №6оп1( ч11632_6 Во5$ЕЗ2 ); 
411616_Е Нсоп$( ч10616_Е ВНо$Е1б6 }; 


Обе функции возвращают целое число в сетевом порядке. 


9106326 пбор1 ( ц10632_6 пеёмогКЗ2 }; 
010616_Е пеов$( \и11616_6 пеёимогк16 ); 


Обе функции возвращают целое число в машинном порядке. 


Функции ВЕ оп1 и ВЕ опз преобразуют целое число из машинного порядка байт 
в сетевой, тогда как функции пёов1 и пеойз выполняют обратное преобразова- 
ние. Заметим, что на «тупоконечных» машинах эти функции ничего не делают 
и обычно определяются в виде макросов: 


#аеЁ1пе ИЕоп] (Хх) (х) 


На «остроконечных» машинах (и для иных архитектур) реализация функций 
зависит от системы. Не надо задумываться, на какой машине вы работаете, по- 
скольку эти функции всегда делают то, что нужно. 


РЕМИ И ШИ Создание эффективных сетевых программ 


Применение этих функций обязательно только для полей, используемых про- 
токолами. Пользовательские данные для протоколов [Р‚, ОЮР иТСР выглядят как 
множество неструктурированных байтов, так что неважно, записаны целые числа 
в сетевом или машинном порядке. Тем не менее функции пеор* и Бёоп* стоит 
применять при передаче любых данных, поскольку тем самым вы обеспечиваете 
возможность совместной работы машин с разной архитектурой. Даже если снача- 
ла предполагается, что приложение будет работать только на одной платформе, 
обязательно настанет день, когда его придется переносить на другую платформу. 
Тогда дополнительные усилия окупятся с лихвой. 


Примечание В общем случае проблема преобразования данных между маши- 
нами с разными архитектурами сложна. Многие программисты 
решают ее, преобразия все числа в код А5СП (или, возможно, в код 
ЕВСОГС для больших машин фирмы 1ВМ). Другой подход связан 
с использованием компоненты ХОК (Емета Леа Кертезетайоп — 
внешнее представление данных), входящей в состав подсистемы 
вызова удаленных процедур (ЕРС — тетыие ртоседите сай), раз- 
работанной фирмой 5ип. Компонента ХОЁЕ определена в ВЕС 
1832 [5пптоабап 1995] и представляет собой набор правил для 
кодирования данных различных типов, а также язык, описыва- 
ющий способ кодирования. Хотя предполагалось, что ХОЕ бу- 
дет применяться как часть ВРС, можно пользоваться этим 
механизмом в ваших программах. В книге [5е0еп5 1999] обсуж- 
дается ХОК иего применение без ВРС. 


И, наконец, следует помнить, что функции разрешения имен, такие как 
деЕвозерупаме и деЕзегурупаме (совет 29), возвращают значения, представ- 
ленные в сетевом порядке. Поэтому следующий неправильный код 


зЕкисЕ зекуепе *зр; 

зегисЕ зоскКааахг_1п *зар; 

5р = дебвекуБупаше( паше, ргобосо1 ); 
зар->$1п_рогЕ = Вбоп$( зр->8_рокЕ ); 


приведет к ошибке, если исполняется не на «тупоконечной» машине. 


Резюме 


В этом разделе рассказывалось, что в ТСР/ТР применяется стандартное пред- 
ставление в сетевом порядке байт для целых чисел, входящих в заголовки прото- 
колов. Здесь также приведены функции Ве оп1, ВЕ опз, пбор1 и пеовз, которые 
преобразуют целые из машинного порядка байт в сетевой и обратно. Кроме того, 
было отмечено, что в общем случае для преобразования форматов данных между 
машинами полезно средство ХОК. 


Р-адреса и номера портов в коде 


Совет 29. Не «зашивайте» [Р-адреса и номера 
портов в код 


У программы есть только два способа получить [Р-адрес или номер порта: 


а 


О из аргументов в командной строке или, если программа имеет графический 
интерфейс пользователя, с помощью диалогового окна либо аналогичного 


механизма; 
о с помощью функции разрешения имен, например деспозЕБупацще или 

де зегуБупаме. 
Примечание Строго говоря, деёзегуБупате - это не функция разрешения 


имени (то есть она не входит в состав ОМ№5-клиента, который 
отображает имена на [Р-адреса и наоборот). Но она рассмотре- 
на вместе с остальными, поскольку выполняет похожие действия. 


Никогда не следует «зашивать» эти параметры в текст программы или помещать 
их в собственный (не системный) конфигурационный файл. И в ОМХ, и в УЛп4о\з 
есть стандартные способы получения этой информации, ими и надо пользоваться. 

Теперь [Р-адреса все чаще выделяются динамически с помощью протокола 
ОНСР (4упагс 603% сопйёигаНоп ргобосо| — протокол динамической конфигура- 
ции хоста). И это убедительная причина избегать их задания непосредственно 
в тексте программы. Некоторые считают, что из-за широкой распространенности 
ОНСР и сложности адресов в протоколе [Руб вообще не нужно передавать прило- 
жению числовые адреса, а следует ограничиться только символическими именами 
хостов, которые приложение должно преобразовать в [Р-адреса, обратившись к функ- 
ции чес позеБупаме или родственным ей. Даже если протокол ОНСР не использу- 
ется, управлять сетью будет намного проще, если не «зашивать» эту информацию 
в код и не помещать ее в нестандартные места. Например, если адрес сети изменяет- 
ся, то все приложения с «зашитыми» адресами просто перестанут работать. 

Всегда возникает искушение встроить адрес или номер порта непосредствен- 
но в текст программы, написанной «на скорую руку», и не возиться с функциями 
типа чееХЬуу. К сожалению, такие программы начинают жить своей жизнью, 
а иногда даже становятся коммерческими продуктами. Одно из преимуществ кар- 
касов и библиотечных функций на их основе (совет 4) состоит в том, что код уже 
написан, так что нет необходимости «срезать углы». 

Рассмотрим некоторые функции разрешения имен и порядок их применения. 
Вы уже не раз встречались с функцией деЕвпозЕЪупапе: 


#1пс1аЯе <пеёаь.в> /* ОМТХ */ 
#1пс1аЯе <илизосКк2.п> /* МпвзосКк */ 


эЕкисЕ Позбепе *деевозЕБупате( сопзЕ сПаг *папе }; 


Возвращаемое значение: указатель на структуру Возбепе в случае успеха, 
МОМ. и код ошибки в переменной | _еггпо - в случае неудачи. 
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Функции деепозЪупапе передается имя хоста, а она возвращает указатель 
на структуру возбсепе следующего вида: 


зЕгисЕ Позбепе { 


спаг *В_папе; /* Официальное имя хоста. */ 

спахг **Н_а]11азез; /* Список синонимов. */ 

116 Б_ааакеуре; /* Тип адреса хоста. */ 

116 В 1епоёв; /* Длина адреса. */ 

сваг **К_аах_ 1136; /* Список адресов, полученных от 0№ 5. */ 


#АеЕ1пе Б_адаг В_аааг_11$36[0]; /* Первый адрес. */ 
| 


Поле в_папме указывает на «официальное» имя хоста, а поле п_а11азез — наспи- 
сок синонимов имени. Поле Н_ааагеуре содержит либо АЕ_ТМЕТ, либо АЕ_ТМЕТб 
взависимости от того, составлен ли адрес в соответствии с протоколом 1Ру4 или 1Руб. 
Аналогично поле _1епдеЪ равно 4 или 16 в зависимости от типа адреса. Все адреса 
типа п_аЯахеуре возвращаются в списке, на который указывает поле п_аЧах_11э6. 
Макрос п_аааг выступает в роли синонима первого (возможно, единственного) адре- 
са в этом списке. Поскольку деЕпозЕБупаме возвращает список адресов, приложение 
может попробовать каждый из них, пока не установит соединение с нужным хостом. 

Работая с функцией деепозЕБупапе нужно учитывать следующие моменты: 


О если хост поддерживает оба протокола [РУ4 и ГРуб, то возвращается только 
один тип адреса. В МХ тип возвращаемого адреса зависит от параметра 
ВЕЗ_О5Е_ТМЕТб системы разрешения имен, который можно явно задать, обра- 
тившись к функции гез_1п16 или установив переменную среду, а также 
с помощью опции в конфигурационном файле ОМ$. В соответствии с \п- 
5оск, всегда возвращается адрес ГРу4; 

О структура позеепЕ находится в статической памяти. Это означает, что функ- 
ция деевпозЕБупаме не рентабельна; 

О указатели, хранящиеся в статической структуре возЕепе, направлены на 
другую статическую или динамически распределенную память, поэтому при 
желании скопировать структуру необходимо выполнять глубокое копирова- 
ние. Это означает, что помимо памяти для самой структуры Возеепе необ- 
ходимо выделить память для каждой области, на которую указывают поля 
структуры, а затем скопировать в нее данные; 

О как говорилось в совете 28, адреса, хранящиеся в списке, на который указы- 
вает поле |_аа9х_1 1%, уже приведены к сетевому порядку байтов, так что 
применять к ним функцию Поп] не надо. 


Вы можете также выполнить обратную операцию -— отобразить адреса хостов 
на их имена. Для этого служит функция деепозЕЪуааа9к. 


#1пс14ае <пеЕаь.в> /* ОМХ. */ 
#1пс1аае <и1пзосКк2.Н> /* М1пзосКк. */ 


зЕгисЕ ВозбепЕ *деЕвозЕБуаЯЯг ( сопзе сраг *ааахг, 116 1еп, 11 Еуре }; 


Возвращаемое значение: указатель на структуру позе епе в случае успеха, 
МОШ. и код ошибки в переменной |_еггпо - в случае неудачи. 
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Несмотря на то, что параметр аааг имеет тип срваг*, он указывает на структу- 
ру 1п_адахг (или 1п6_адах в случае 1Руб). Длина этой структуры задается пара- 
метром 1еп, а ее тип (АЕ_ТМЕТ или АЕ_ТМЕТб) — параметром Еуре. Предыдущие 
замечания относительно функции деевозЕБупаме касаются и дебпоз®Буааах. 

Для хостов, поддерживающих протокол 1Руб, функции деепозЕБупане недо- 
статочно, так как нельзя задать тип возвращаемого адреса. Для поддержки Руб 
(и других адресных семейств) введена общая функция деевозЕЪупаще2, допус- 
кающая получение адресов указанного типа. 


#1пс1аае <пеёаь.в> /* ОМТХ */ 


116 аЁ ); 


зЕгисЕ БозбепЕе *десрозЕБупаме2 ( сопзЕ сваг *паше, 


Возвращаемое значение: указатель на структуру ПозЕепё в случае успеха, 
МОБ и код ошибки в переменной п_еггпо - в случае неудачи. 


Параметр аЁ- это адресное семейство. Интерес представляют только возмож- 
ные значения АР_ТМЕТ или АР_ТМЕТ6. Спецификация УЛпзоск не определяет функ- 
цию деЕпозЕБупаще2, а использует вместо нее функционально более богатый 
(и сложный) интерфейс ИЗАЦШОоОКир$егу1сеМехе. 


Примечание Взаимодействие протоколов 1Ру4 и [Руб — это в значительной 
мере вопрос обработки двух разных типов адресов. И функция 
деЕВозЕБупате2 предлагает один из способов решения этой 
проблемы. Эта тема подробно обсуждается в книге [5е0епз 
1998], где также приведена реализация описанной в стандарте 
РО5Х функции деёаааг1 пЕо. Эта функция дает удобный, не 
зависящий от протокола способ работы с обоими типами адре- 
сов. С помощью деЕаааг1 р Ео можно написать приложение, ко- 
торое будет одинаково работать и с [Ра4, и с 1Рьб. 


Раз системе (или службе ОМ№$) разрешено преобразовывать имена хостов в [Р- 
адреса, почему бы ни сделать то же и для номеров портов? В совете 18 рассматри- 
вался один способ решения этой задачи, теперь остановимся на другом. Так же, 
как деспозЕБупаце и девозБуаааг выполняют преобразование имени хоста 
в адрес и обратно, функции десзегуБупапе и деЕзегурурог® преобразуют сим- 
волическое имя сервиса в номер порта и наоборот. Например, сервис времени дня 
Чауе1те прослушивает порт 13 в ожидании ТСР-соединений или ОПР-дата- 
грамм. Можно обратиться к нему, например, с помощью программы Ее1пек: 


Се1пеЕ Ъза 13 


Однако необходимо учитывать, что номер порта указанного сервиса равен 13. 
К счастью, се1пек понимает и символические имена портов: 


се1пеЕ ЪзЯ ЯауЕ1те 


Теше& выполняет отображение символических имен на номера портов, вы- 
зывая функцию деезегуБупаме; вы сделаете то же самое. В листинге 2.3 вы 
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увидите, что в предложенном каркасе этот вызов уже есть. Функция зе _а@агезз 
сначала оперирует параметром рогЕ как представленным в коде АСИ це- 
лым числом, то есть пытается преобразовать его в двоичную форму. Если это 
не получается, то вызывается функция деезегурупапе, которая ищет в базе 
данных символическое имя порта и возвращает соответствующее ему число- 
вое значение. 

Прототип функции де зегуьупаме похож на деепозЕЪупаме: 


#1пс1иае <пебаь.Н> /* ОХ */ 
#1пс]1ацАе <и1пзосКк2.Н> /* УлпзосКк */ 


з6гасЕ зехуепЕе *деезегуБупаме( сопзе сваг *пате, сопзе сваг *ргоЕо }; 


Возвращаемое значение: указатель на структуру зегуепЕ в случае успеха, 
МОГ - в случае неудачи. 


Параметр папе — это символическое имя сервиса, например «Чауйте». Если 
параметр ргоёо не равен МОМ, то возвращается сервис, соответствующий задан- 
ным имени и типу протокола, в противном случае — первый найденный сервис 
с именем паме. Структура зехуепЕ содержит информацию о найденном сервисе: 


зегисе зекуепе { 


сраг *з_паме; /* Официальное имя сервиса. */ 
сраг **5_а11азез; /* Список синонимов. */ 

1706 з_роге; /* Номер порта. */ 

сраг *з_ргобо; /* Используемый протокол. */ 


7% 


Поля з_пацще и з_а11азез содержат указатели на официальное имя сервиса 
и его синонимы. Номер порта сервиса находится в поле з_роге. Как обычно, этот 
номер уже представлен в сетевом порядке байтов. Протокол (ТСР или ОПР), ис- 
пользуемый сервисом, описывается строкой в поле з_ргого. 

Вы можете также выполнить обратную операцию - найти имя сервиса по но- 
меру порта. Для этого служит функция деёзегуБурокге: 


#1пс1аае <пебаь.в> /* ОХ. */ 
#1пс1аае <и1тзосКк2.Н> /* ИпзосКк. */ 


зегисё зекуепЕ *дебзегуБуроге ( 116 рогЕЁ, сопзЕ спаг *ргоЕо ); 


Возвращаемое значение: указатель на структуру зегуепе в случае успеха, 
МОН. - в случае неудачи 


Передаваемый в параметре рогЕ номер порта должен быть записан в сетевом 
порядке. Параметр ргоёо имеет тот же смысл, что и раньше. 

С точки зрения программиста, данный каркас и библиотечные функции ре- 
шают задачи преобразования имен хостов и сервисов. Они сами вызывают нуж- 
ные функции, а как это делается, не должно вас волновать. Однако нужно знать, 
как ввести в систему необходимую информацию. 
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Обычно это делается с помощью одного из трех способов: 


а 2№5; 
а сетевой информационной системы (№15) или №15; 
о файлов НозЕЁз и зегу1сез. 


0№5 (Поташ Маше Зу$ещ — служба доменных имен) -— это распределенная 
база данных для преобразования имен хостов в адреса. 


Примечание ОМ используется также для маршрутизации электронной почты. 
Когда посылается письмо на адрес уэт1Ер@зотесопрапу. сом, 
с помощью ОМ5 ищется обработчик (или обработчики) почты 
для компании вотесотрапу . сот. Подробнее это объясняется 
в книге [Афи? апа Глп 1998], 


Ответственность за хранение данных распределяется между зонами (грубо гово- 
ря, они соответствуют адресным доменам) и подзонами. Например, Ывсотрапу.сот 
может представлять собой одну зону, разбитую на несколько подзон, соответству- 
ющих отделам или региональным отделениям. В каждой зоне и подзоне работает 
один или несколько О№$-серверов, на которых хранится вся информация о хостах 
в этой зоне или подзоне. Другие ОМ$-серверы могут запросить информацию у дан- 
ных серверов для разрешения имен хостов, принадлежащих компании В1Сотрапу. 


Примечание Система )М№5 — это хороший пример ООР-приложения. Как пра- 
вило, обмен с ОМ5-сервером происходит короткими транзакци- 
ями. Клиент (обычно одна из функций разрешения имен) посы- 
лает ПОР-датаграмму, содержащую запрос к ОМ5-серверу. 
Если в течение некоторого времени ответ не получен, то пробу- 
ется другой сервер, если таковой известен. В противном случае 
повторно посылается запрос первому серверу, но с увеличенным 
тайм-аутом. 


На сегодняшний день подавляющее большинство преобразований между име- 
нами хостов и [Р-адресами производится с помощью службы О№5. Даже сети, не 
имеющие выхода вовне, часто пользуются 0$, так как это упрощает администри- 
рование. При добавлении в сеть нового хоста или изменении адреса существующего 
нужно обновить только базу данных ОМ№$, а не файлы Нозёз на каждой машине. 

Система № и последовавшая за ней №[$+ предназначены для ведения центра- 
лизованной базы данных о различных аспектах системы. Помимо имен хостов 
и [Р-адресов, $ может управлять именами сервисов, паролями, группами и дру- 
гими данными, которые следует распространять по всей сети. Стандартные функ- 
ции разрешения имен (о них говорилось выше) могут опрашивать и базы данных 
МГ. В некоторых системах МГ5-сервер при получении запроса на разрешение име- 
ни хоста, о котором у него нет информации, автоматически посылает запрос ОМ5- 
серверу. В других системах этим занимается функция разрешения имен. 

Преимущество системы М5 в том, что она централизует хранение всех рас- 
пространяемых по сети данных, упрощая тем самым администрирование больших 
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сетей. Некоторые эксперты не рекомендуют М5, так как имеется потенциальная 
угроза компрометации паролей. В системе №15+ эта угроза снята, но все равно 
многие опасаются пользоваться ей. №1$ обсуждается в работе [Вго\п 1994]. 

Последнее и самое неудобное из стандартных мест размещения информации 
об именах и 1Р-адресах хостов — это файл НозЕз, обычно находящийся в каталоге 
/ефс на каждой машине. В этом файле хранятся имена, синонимы и ГР-адреса хо- 
стов в сети. Стандартные функции разрешения имен просматривают также и этот 
файл. Обычно при конфигурации системы можно указать, когда следует просмат- 
ривать файл ПозЕз — до или после обращения к службе ОМЗ. 

Другой файл -— обычно /еёс/зег\у1сез — содержит информацию о соответ- 
ствии имен и портов сервисов. Если М5 не используется, то, как правило, на каж- 
дой машине имеется собственная копия этого файла. Поскольку он изменяется 
редко, с его администрированием не возникает таких проблем, как с файлом ВозЕз. 
В совете 17 было сказано о формате файла зег\1сев. 

Основной недостаток файла позЕз — это очевидное неудобство его сопровож- 
дения. Если в сети более десятка хостов, то проблема быстро становится почти не- 
разрешимой. В результате многие эксперты рекомендуют полностью отказаться от 
такого метода. Например, в книге [Т.евеу 1996] советуется следующее: «Есть толь- 
ко одна причина не пользоваться службой ОМ№$ — если ваш компьютер не подсое- 
динен к сети». 


Резюме 


В этом разделе рекомендовано не «зашивать» адреса и номера портов в про- 
грамму. Также рассмотрено несколько стандартных схем получения этой инфор- 
мации и обсуждены их достоинства и недостатки. 


Совет 30. Разберитесь, что такое подсоединенный 
УОР-сокет 


Здесь рассказывается об использовании вызова соппесЕ применительно 
к протоколу ОПР. Из совета 1 вам известно, что (ЮР - это протокол, не требую- 
щий установления соединений. Он передает отдельные адресованные конкретно- 
му получателю датаграммы, поэтому кажется, что слово «соппес&» (соединить) тут 
неуместно. Следует, однако, напомнить, что в листинге 3.6 вы уже встречались 
с примером, где вызов соппес® использовался в запускаемом через 1пека ООР- 
сервере, чтобы получить (эфемерный) порт для этого сервера. Только так 1пеЕ Я 
мог продолжать прослушивать датаграммы, поступающие в исходный хорошо из- 
вестный порт. 

Прежде чем обсуждать, зачем нужен вызов соппесе для (ОР-сокета, вы дол- 
жны четко представлять себе, что собственно означает «соединение» в этом кон- 
тексте. При использовании ТСР вызов соппесЕ инициирует обмен информацией 
о состоянии между сторонами с помощью процедуры трехстороннего квитирова- 
ния (рис. 3.14). Частью информации о состоянии является адрес и порт каждой 
стороны, поэтому можно считать, что одна из функций вызова соппесь в прото- 
коле ТСР - это привязка адреса и порта удаленного хоста к локальному сокету. 
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Хотя полезность вызова соппес® в протоколе ОЮР может показаться сомни- 
тельной, но вы увидите, что, помимо некоторого повышения производительнос- 
ти, он позволяет выполнить такие действия, которые без него были бы невозмож- 
ны. Рассмотрим причины использования соединенного сокета (ЮР сначала 
с точки зрения отправителя, а потом — получателя. 

Прежде всего, от подсоединенного ОПР-сокета вы получаете возможность ис- 
пользования вызова зепа или мг1{е (в ОМ[Х) вместо зепд6о. 


Примечание Для подсоединенного ПОР-сокета можно использовать и вызов 
зепао, но в качестве указателя на адрес получателя надо за- 
давать МО, а в качестве его длины -— нуль. Возможен, конечно, 
и вы308 зепатзсд, но и в этом случае поле пзд_пате в структуре 
шзаваг должно содержать МОГУТ, а поле тзд_пате1еп - нуль. 


Само по себе это, конечно, немного, но все же вызов соппесЕ действительно 
дает заметный выигрыш в производительности. 

В реализации В$О зепабо - это частный случай соппесе. Когда датаграмма 
посылается с помощью зепасо, ядро временно соединяет сокет, отправляет дата- 
грамму, после чего отсоединяет сокет. Изучая систему 4.3В5Р и тесно связан- 
ную с ней $ипО5 4.1.1, Партридж и Пинк [Рагел4ве апа Ршк 1993] заметили, что 
такой способ соединения и разъединения занимает почти треть времени, уходяще- 
го на передачу датаграммы. Если не считать усовершенствования кода, который 
служит для поиска управляющего блока протокола (РСВ - ргобосо]| сопёго| Моск) 
и ассоциирован с сокетом, исследованный этими авторами код почти без измене- 
ний вошел в систему 4.4ВЗР и основанные на ней, например ЕгееВЗО. В частно- 
сти, эти стеки по-прежнему выполняют временное соединение и разъединение. 
Таким образом, если вы собираетесь посылать последовательность ООР-дата- 
грамм одному и тому же серверу, то эффективность можно повысить, предвари- 
тельно вызвав соппесё. 

Этот выигрыш в производительности характерен только для некоторых реа- 
лизаций. А основная причина, по которой отправитель ООР-датаграмм подсоеди- 
няет сокет, — это желание получать уведомления об асинхронных событиях. Пред- 
ставим, что надо послать ОЮР-датаграмму, но никакой процесс на другой стороне 
не прослушивает порт назначения. Протокол ОПР на другом конце вернет {СМР- 
сообщение о недоступности порта, информируя тем самым ваш стек ТСР/ТР, но 
если сокет не подсоединен, то приложение не получит уведомления. Когда вы вы- 
зываете зеп фо, в начало сообщения добавляется заголовок, после чего оно пере- 
дается уровню ГР, где инкапсулируется в [Р-датаграмму и помещается в выход- 
ную очередь интерфейса. Как только датаграмма внесена в очередь (или отослана, 
если очередь пуста), зепаЕо возвращает управление приложению с кодом нор- 
мального завершения. Иногда через некоторое время (отсюда и термин асинхрон- 
ный) приходит 1{СМР-сообщение от хоста на другом конце. Хотя в нем есть копия 
ЯЮрР-заголовка, у вашего стека нет информации о том, какое приложение посы- 
лало датаграмму (вспомните совет 1, где говорилось, что из-за отсутствия уста- 
новленного соединения система сразу забывает об отправленных датаграммах). 
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Если же сокет подсоединен, то этот факт отмечается в управляющем блоке прото- 
кола, связанном с сокетом, и стек ТСР/1Р может сопоставить полученную копию 
ОПрР-заголовка с тем, что хранится в РСВ, чтобы определить, в какой сокет на- 
править [СМР-сообщение. 

Можно проиллюстрировать данную ситуацию с помощью вашей программы 
царс11епе (листинг 3.5) из совета 17 -— следует отправить датаграмму в порт, ко- 
торый не прослушивает ни один процесс: 


Ьза: $ чарс11епе Ьва 9000 

Не11о, Мог1а! 

^С Клиент "зависает" и прерывается вручную. 
Ьза: $ 


Теперь модифицируем клиент, добавив такие строки 


1Е ( соппесе( $, ( зЕекасЕ зосКа@ахг * }&реег, з12еоЁ( реег } ) ) 
еггохг( 1, еггпо, "ошибка вызова соппесёе”" ); 


сразу после вызова функции и9р_с11епе. Если назвать эту программу иарсопл1 
и запустить ее, то вы получите следующее: 


Ьза: $ чарсопа1 Ьва 9000 

Не11о, Мог1а! 

ирЯсопп1: ошибка вызова зепаво: босКкее 13 а1геаЧу соппесееа (56) 
Ьза: $ 


Ошибка произошла из-за того, что вы вызвали зепабо для подсоединенного 
сокета. При этом зепако потребовал от (ЮР временно подсоединить сокет. Но 
ОБР определил, что сокет уже подсоединен и вернул код ошибки ЕТЗСОММ. 

Чтобы исправить ошибку, нужно заменить обращение к зепдео на 


ГС = зепа( 5, БаЕ, зЕт1еп( БоЕЁ ), 0); 


Назовем новую программу парсопп2. После ее запуска получится такой ре- 
зультат: 


за: $ аарсопр1 Ьза 9000 
Не11о, Мот1а! 


ирЯсопп2: ошибка вызова гесуЁгом: СоппесЕ1оп геЕазеа (61) 
за: $ 


На этот раз ошибку ЕСОММВЕРОЗЕР вернул вызов гесуЁгот. Эта ошибка - ре- 
зультат получения приложением 1{СМР-сообщения о недоступности порта. 

Обычно у получателя нет причин соединяться с отправителем (если, конечно, 
ему самому не нужно стать отправителем). Однако иногда такая ситуация может 
быть полезна. Вспомним аналогию с телефонным разговором и почтой (совет 1). 
ТСР-соединение похоже на частный телефонный разговор - в нем только два участ- 
ника. Поскольку в протоколе ТСР устанавливается соединение, каждая сторона зна- 
ет о своем партнере и может быть уверена, что всякий полученный байт действи- 
тельно послал партнер. 

С другой стороны, приложение, получающее ООР-датаграммы, можно срав- 
нить с почтовым ящиком. Как любой человек может отправить письмо по данному 
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адресу, так и любое приложение или хост может послать приложению-получате- 
лю датаграмму, если известны адрес и номер порта. 

Иногда нужно получать датаграммы только от одного приложения. Получаю- 
щее приложение добивается этого, соединившись со своим партнером. Чтобы уви- 
деть, как это работает, напишем ООР-сервер эхо-контроля, который соединяется 
с первым клиентом, отправившим датаграмму (листинг 3.35). 


Листинг 3.35. ЦОР-сервер эхо-контроля, выполняющий соединение 


иарсоппвегу.с 
1 #1пс1аае "ебср.В" 
2 116 ма1п( 116 агас, свак **агах } 
3 { 
4 зегисЕ зосКаЯаг_1п реек; 
5 ЗОСКЕТ 3; 
6 116 гс; 
7 106 1еп; 
8 саг БаЕ[Г 120 |]; 


9 ТмТТ(); 
10 $5 = чар зекуег( МОШЬ, агау[ 1 ] ); 
11 1еп = з12еоЁ( реек ); 
12 гс = гесуЁгот( $, РаЁ, з1хеоЁ( БъЕ }, 
13 0, ( зЕгасЕе зоскКаааг * )&реек, &1еп }; 
14 Е (тс < 0) 
15 еггог( 1, еггпо, "ошибка вызова гесуЁгою" ); 
16 1Е ( сопресё( $, ( зЕгасЕ зоскааахг * )&реег, 1еп } } 
17 еггог( 1, еггпо, "ошибка вызова соппесе" ); 
18 %111е ( зЕгпспр( БаЁ, "аопе", 4) !=0 ) 
19 { 
20 1Е ( зепа( з, БаЕЁ, гс, 0) <0) 
21 еггог( 1, егхпо, "ошибка вызова зеп@а" ); 
22 гс = гесу( з, БаЕЁ, эз1хеоЁ( БаЁ ), 0}; 
23 1Е (тс < 0) 
24 еггог( 1, егкпо, "ошибка вызова гесу" ); 
25 } 
26 ЕХТТ( О); 
27 } 


иарсоппжегу. с 


9-15 — Выполняем стандартную инициализацию ОПР и получаем первую дата- 
грамму, сохраняя при этом адрес и порт отправителя в переменной реег. 

16-17 Соединяемся с отправителем. 

18-25 В цикле отсылаем копии полученных датаграмм, пока не придет дата- 
грамма, содержащая единственное слово «4опе». 


Для экспериментов с сервером идрсоппизег\у можно воспользоваться клиен- 
том иарсопп2. Сначала запускается сервер для прослушивания порта 9000 в ожи- 
дании датаграмм: 
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царсоппзегу 9000 


а затем запускаются две копии парсопп2, каждая в своем окне. 


ЬзЯ: $ чарсопп2 Бва 9000 рзЯ: $ чарсопп2 Бва 9000 

опе Емо 

опе царсопп2: ошибка вызова гесуЁгом; 
СоппесЕ1оп геЁазеа (61) 

ЕВгее за: $ 

Епгее 

допе 

^С 

за: $ 


Когда в первом окне вы набираете опе, сервер иарсоппзеку возвращает ко- 
пию датаграммы. Затем во втором окне вводите Е мо, но гесуЁгом возвращает код 
ошибки ЕСОММВЕРОЗЕХ. Это происходит потому, что (ОР вернул 1СМР-сообще- 
ние о недоступности порта, так как ваш сервер уже соединился с первым экзем- 
пляром ичарсопп2 и не принимает датаграммы с других адресов. 


Примечание Адреса отправителя у обоих экземпляров чарсопп2, конечно, оди- 
наковы, но эфемерные порты, выбранные стеком ТСР/ТР, различны. 
В первом окне вы набираете ЕВгее, дабы убедиться, что иар- 
соппзегу все еще функционирует, а затем — аопе, чтобы 
остановить сервер. В конце прерываем вручную первый экзем- 
пляр чарсоппа. 


Как видите, иарсоппзегу не только отказывается принимать датаграммы от 
другого отправителя, но также информирует приложение об этом факте, посылая 
[СМР-сообщение. Разумеется, чтобы получить это сообщение, клиент также дол- 
жен подсоединиться к серверу. Если бы вы прогнали этот тест с помощью перво- 
начальной версии клиента иЯрс11еп вместо иарсопп2, то второй экземпляр кли- 
ента просто «завис» после ввода слова «Чопе». 


Резюме 


В этом разделе рассмотрено использование вызова соппесе в протоколе (ОР. 
Хотя на первый взгляд может показаться, что для протокола без установления со- 
единения это не имеет смысла, но, как вы видели, такое действие, во-первых, по- 
вышает производительность, а во-вторых, оно необходимо при желании получать 
некоторые сообщения об ошибках при отправке ООР-датаграмм. Здесь также опи- 
сано, как использовать соппесЕ для приема датаграмм только от одного хоста. 


Совет 31. Помните, что С - не единственный 
язык программирования 


До сих пор все примеры в этой книге были написаны на языке С, но, конечно, 
это не единственно возможный выбор. Многие предпочитают писать на С++, ]ауа 
или даже Разса|. В этом разделе будет рассказано об использовании языков сценари- 
ев для сетевого программирования и приведено несколько примеров на языке Рей. 
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Вы уже встречались с несколькими примерами небольших программ, напи- 
санных специально для тестирования более сложных приложений. Например, 
в совете 30 использованы простые и похожие программы иарс11еп, иарсопп1 
и чарсопп2 для проверки поведения подсоединенного ОПЮР-сокета. В таких слу- 
чаях имеет смысл воспользоваться каким-либо языком сценариев. Сценарии про- 
ще разрабатывать и модифицировать хотя бы потому, что их не надо компилиро- 
вать и компоновать со специальной библиотекой, а также создавать файлы сборки 
проекта (Маке#]е) - достаточно написать сценарий и сразу же запустить его. 

В листинге 3.36 приведен текст минимального Рег|-сценария, реализующего 
функциональность программы и9рс11епе. 

Хотя я не собираюсь писать руководство по языку Рет|, но этот пример стоит 
изучить подробнее. 


Примечание Глава 6 стандартного учебника по Рей ГЦ еЕ а“. 1996 ] посвящена 
имеющимся в этом языке средствам межпроцессного взаимодей- 
ствия и сетевого программирования. Дополнительную инфор- 
мацию о языке Рей можно найти на сайте р;/ Дочирейсот. 


Листинг 3.36. Версия программы иарс!ег: на языке Рей 


риарс11епе 
1#! /азхг/Ь1п/рег15 
2 изе ЗоскеЕ; 
3 $ВовзЕ = зВ1ЕЕ || "1оса1Возё"; 
4 $рогЕ = вВ1ЕЕ || "есВо"; 
5 $рохгЕ = дебзегурупате( $рогё, "иар" ) 1Е $рогё =- /\О/; 
6 бреег = зосКа@ааг_1п( $рогЕ, 1пее_абоп( $Возё } ); 
7 воскее( $, РЕ _ТМЕТ, $0СК_ОСКАМ, 0 ) || а1е "ошибка вызова зоскее $!"; 
8 ир11е ( $11ще = <9То7тм№> ) 
9: 
10 аеЁ1пея( зепа( $, $11пе, 0, $реег ) ) || @1е "ошибка вызова зепа $!"; 
11 деЕ1пеа( гесу( $, $11пе, 120, 0 ) ) || а1е "ошибка вызова гесу $!"; 
12 ришЕё $Пше; 
13 } 
риарс11епё 
Инициализация 
2 В этой строке Рег] делает доступными сценарию определения некото- 


рых констант (например, РЕ_ТМЕТ). 


Получение параметров командной строки 

3-4 Из командной строки читаем имя хоста и номер порта. Обратите вни- 
мание, что этот сценарий делает больше, чем программа на языке С, так 
как по умолчанию он присваивает хосту имя 1оса1поз%, а порту — 
есНно, если один или оба параметра не заданы явно. 


Заполнение структуры 5осКадаг_{п и получение сокета 


5-6 Этот код выполняет те же действия, что и функция зеё_аЯагезз в ЛИ- 
стинге 2.3 в совете 4. Обратите внимание на простоту кода. В этих двух 


РАМЕ — Создание эффективных сетевых программ 


строчках 1Р-адрес хоста принимается как числовой и его имя симво- 
лическое, а равно числовое или символическое имя сервиса. 
7 Получаем ОПОР-сокет. 


Основной цикл 

8-13 Так же, как в иарс11еп%, читаем строки из стандартного ввода, отправ- 
ляем их удаленному хосту, читаем от него ответ и записываем его на 
стандартный вывод. 


Хотя знакомые сетевые функции иногда принимают несколько иные аргумен- 
ты и могут возвращать результат непривычным образом, но, в общем, программа 
в листинге 3.36 кажется знакомой и понятной. Тот, кто знаком с основами сетевого 
программирования и хотя бы чуть-чуть разбирается в Ре!|, может добиться высо- 
кой производительности. 

Для сравнения в листинге 3.37 представлен ТСР-сервер эхо-контроля. Вы мо- 
жете соединиться с этим сервером с помощью программы {ее или любого друго- 
го ТСР-приложения, способного вести себя как клиент эхо-сервера. 

Здесь также видна знакомая последовательность обращений к АР] сокетов 
и, даже не зная языка Рег|, можно проследить за ходом выполнения программы. 
Следует отметить две особенности, присущие Рег|: 


О вызов ассерк на строке 11 возвращает ТВОЕ, если все хорошо, а новый со- 
кет возвращается во втором параметре (51). В результате естественно выг- 
лядит цикл Еог, в котором принимаются соединения; 

О поскольку гесу возвращает адрес отправителя (или специальное значение 
ипаеЕ), а не число прочитанных байт, получая длину строки $11пе (строка 
16), следует явно проверять, не пришел ли признак конца файла. Оператор 
1азё выполняет те же действия, что Ьгеак в языке С. 


Листинг 3.37. Версия эхо-сервера на языке Реп 


ресво5 
1 #! /азку/Б1п/рег15 
2 изе ЗоскКее; 
3 брохЕ = э61Ёб; 
4 $рогЕ = дебсзегуБупаме( $рогЕ, 'Еср' ) 1Е $рокЕ =- /\О/; 
5 Я1е "Тпуа11@А роге" чп1ез$ $рогЕ; 
6 зоскеЕ( $, РЕ_ТМЕТ, $ОСК_5ТВЕАМ, 0 )} || а1е "зоскКеё: $!"; 
7 зеезосКоре( $, $0._ЗОСКЕТ, $0_ВЕОЗЕАООВ, раск( '1', 1) } || 
8 а1е "зебезосКоре: $!"; 
9 Б1па( 5, зоскаааг_1п( $рогЕе, ТМАОШОВ_АМУ ) } || а1е "Ъала: $!"; 
10 115з6сеп( $, ЗОМАХСОММ ); 
11 Еог( ; ассер®е( $1, $ ); с1озе{ $1 ) ) 
12 { 
13 \р1]е ( ТВОЕ )} 
14 { 
15 ЗеЁ1пеа( гесу( $1, $11пе, 120, 0 ) ) || @1е "кесу: $1и"; 


16 1азе 1Ё 1епаев( $111е ) == 0; 
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17 деЁ1пеЯ( зепа( $1, $11пе, 0 ) ) || ае "вела: $!"; 
18 } 
19} 
ресроз 


Как видно из этих двух примеров, языки сценариев вообще и Рет| в частности — 
это отличный инструмент для написания небольших тестовых программ, создания 
прототипов более крупных систем и утилит. Рег] и другие языки сценариев активно 
применяются при разработке \\еБ-серверов и специализированных \!е-клиентов. 
Примеры рассматриваются в книгах [Сазёго 1998] и [РабсВеё апа У’аейе 1998]. 

Помимо простоты и скорости разработки прототипа, есть и другие причины 
для использования языков сценариев. Одна из них - наличие в таких языках спе- 
циальных возможностей. Например, Рег| обладает прекрасными средствами для 
манипулирования данными и работы с регулярными выражениями. Поэтому во 
многих случаях Рег| оказывается удобнее таких традиционных языков, как С. 

Предположим, что каждое утро вам надо проверять, не появились ли в конферен- 
ции сотр.рговосо|5.ёср-1р новые сообщения о протоколах ТСРи ОПР В листинге 3.38 
приведен каркас Рег|-сценария для автоматизации решения этой задачи. В таком 
виде сценарий не очень полезен, так как он показывает все сообщения от сервера 
новостей, даже старые; отбор сообщений осуществляется довольно грубо. Можно 
было бы без труда модифицировать сценарий, ужесточив критерий отбора, но луч- 
ше оставить его таким, как есть, чтобы не запутаться в деталях языка Ре!. Подроб- 
нее протокол передачи сетевых новостей (ММТР) рассматривается в ВЕС 977 [Кап- 
{ог апа Гарзеу 1986]. 


Листинг 3.38. Реп-сценарий для формирования дайджеста из сетевых конференций 


Есрпеиз 
#! /ивг/р1п/рег15 
ие боскее; 
бПозЕ = 1пеб_абоп( 'ппёр.1х.пебсом.сом') || @1е "хост: $!"; 
брогЕ = дебзегуБупаме( ‘'ппбр', '6ср' ) || @1е "некорректный порт"; 
зоскее( $, РР_ТМЕТ, ЗОСК_5ТВЕАМ, 0 } || @1е "зоскКеё: $!"; 
соппесе( $, зоскКаЯахг_1п( $рогЕ, $розЕ ) ) || а1е "соппесё: $!"; 
зе1есе ($ )}; 
Е 


зе1есе( $Утроот )}; 
рг1пЕ 5 "дгоир сопр.рговосо1в.Еср-1р\г\п"; 
\1]е ( $11п1е = <5> ) 
| 
1азЕ 1Е $111е =- /^211/; 
} 
($хс, $Еоба1, $збахгЕ, $епа } = зр116( /\5в/, $11ще }; 
рк1пЕ $ "хоуег $з6аге-5епа\паи1е\г\п"; 


нон на на на на 
лиш ноюючаньвььюн 


17 мЪ11е ( $111е = <$> ) 
18 { 
19 ( бпо, $заЪ, базЕВ, баабе ) = зр11%( /\Е/, $11ше ); 
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20 рг1пЕ "$по, $заб, $ааее\п" 1Ё $заЬ =- /ТСР|ООРИ/; 
21 } 
22 с1озе( $5); 
Есрпем9 


Инициализация и соединение с сервером новостей 
2-6 — Это написанный на Рег| аналог логики инициализации стандартногф 
ТСР-клиента. 


Установить режим небуферизованного ввода/вывода 

7-9 В Рег] функция рг1пе вызывает стандартную библиотеку ввода/выво 
да, а та, как упоминалось в совете 17, буферизует вывод в сокет. Эт 
три строки отключают буферизацию. Хотя по виду оператор зе1ес 
напоминает системный вызов зе1ес®, который рассматривался ране 
в действительности он просто указывает, какой файловый дескрипто 
будет использоваться по умолчанию. Выбрав дескриптор, вы может 
отменить буферизацию вывода в сокет $, задав ненулевое значение спе 
циальной переменной $ |, используемой в Реп. 


Примечание Строго говоря, это не совсем так. Эти действия приводя 
к тому, что после каждого вызова иг1Ее или рг1пЕ для данног 
дескриптора автоматически выполняется функция ЕЕТизв. Н 
результат оказывается таким же, как если бы вывод в соке 


был не буферизован. 
———ы—ыы=—ы—ы—ы——ы—ы— 


В строке 9 зЕ9оц{ восстанавливается как дескриптор по умолчанию. 


Выбрать группу сотр.ргоосо5.{кр-1р 

10-14 Посылаем серверу новостей команду дхочр, которая означает, что те 
кущей группой следует сделать сопр.ргофосо1з.Еср-1р. Сервер =] 
вечает строкой вида 


211 соба1_агс1с1ез ЁЕ1г$е_аге1с1е# 1а5е_агё1с1е# агоцр_памезрасе 


В строке 13 вы ищете именно такой ответ, отбрасывая все строки, кото 

рые начинаются не с кода ответа 211. Обратите внимание, что операто 

<...> сам разбивает на строки входной поток, поступающий от ТС 
15-16 Обнаружив ответ на команду агоцр, нужно послать серверу строки 


хоуег Е1хг5_аге1с1е#-1аз6_аге1с1е# 
чате 


Команда хоуег запрашивает сервер, заголовки всех статей с номерами из за 
данного диапазона. Заголовок содержит список данных, разделенных символам 
табуляции: номер статьи, тема, автор, дата и время, идентификатор сообщени 
идентификаторы сообщений для статей, на которую ссылается данная, число бай 
тов и число строк. Команда <а1Е приказывает серверу разорвать соединение, таю 
как запросов больше не будет. 
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Отбор заголовков статей 

17-20 Читаем каждый заголовок, выделяем из него интересующие нас поля 
и оставляем только те заголовки, для которых в теме присутствует стро- 
ка «ТСР» или «ОПР». 

Запуск Есрпемз дает следующий результат: 


Ь5а: $ Еесрпеив 

74179, Ве: ПОР па 1сазе, Тва, 22 4а1 1999 21:06:47 СМТ 

74181, Ве: ПОР ши161сазЕ, ТНа, 22 Та1 1999 21:10:45 -0500 

74187, Ве: ПОР па1е1сазе, Тва, 22 4и1 1999 23:23:00 +0200 

74202, Ве: МТ 4.0 $егуег ап@ ТСР/ТР, Ег1, 23 да] 1999 11:56:07 СМТ 
74227, Меи бе1Ко ТСР/ТР СБ1р, ТВа, 22 Фа] 1999 08:39:09 -0500 
74267, МАТТСР ргоБ1етз, Моп, 26 441 1999 13:18:14 -0500 

74277, Ве: Мем бе1Ко ТСР/ТР СП1р, Тра, 26 Фа1 1999 23:33:42 СМТ 
74305, ТСР Реёг1 МеЕ по4е1, Мея, 28 9и1 1999 02:27:20 +0200 

Ьза: $ 


Помимо языка Рег|, есть и другие языки сценариев, пригодные для сетевого 
программирования, например: 


о ТСЁЬ/Ехресе; 

о Руфоп; 

о ]ЛауаЗспре; 

о \У!15ча| Вазс (для УЛа9до\5). 


Их можно использовать для автоматизации решения простых сетевых задач, 
построения прототипов и быстрого создания удобных утилит или тестовых при- 
меров. Как вы видели, языки сценариев часто проще применять, чем традицион- 
ные компилируемые языки программирования, поскольку интерпретатор берет на 
себя многие технические детали (конечно, расплачиваясь эффективностью). Уси- 
лия, потраченные на овладение хотя бы одним из таких языков, окупятся ростом 
производительности труда. 


Резюме 


В этом разделе говорилось об использовании языков сценариев в сетевом про- 
граммировании. Нередко их применение имеет смысл при написании небольших 
утилит и тестовых программ. 


Совет 32. Определите, на что влияют размеры буферов 


Здесь приводятся некоторые эвристические правила для задания размеров 
буферов приема и передачи в ТСР В совете 7 обсуждалось, как задавать эти раз- 
меры с помощью функции зе зоскор*. Теперь вы узнаете, какие значения следу- 
ет устанавливать. 

Необходимо сразу отметить, что выбор правильного размера буфера зависит 
от приложения. Для интерактивных приложений типа {е|пеё желательно устанав- 
ливать небольшой буфер. Этому есть две причины: 


НИТЯМИ! — Создание эффективных сетевых программ 


о обычно клиент посылает небольшой блок данных серверу и ждет ответа. По- 
этому выделять большой буфер для таких соединений - пустая трата сис- 
темных ресурсов; 

о при большом буфере реакция на действия пользователя происходит не 
сразу. Например, если пользователь выводит на экран большой файл и на- 
жимает комбинацию клавиш прерывания (С&1+С), то вывод не прекратит- 
ся, пока в буферах есть данные. Если буфер велик, то до реального прерыва- 
ния просмотра может пройти заметное время. 


Знать размер буфера необходимо для расчета максимальной производитель- 
ности. Например, это относится к приложениям, которые передают большие объе- 
мы данных преимущественно в одном направлении. Далее будут рассматриваться 
именно такие приложения. 

Как правило, для получения максимальной пропускной способности рекомен- 
дуется, чтобы размеры буферов приема и передачи были не меньше произведения 
полосы пропускания на задержку. Как вы увидите, это правильный, но не слишком 
полезный совет. Прежде чем объяснять причины, разберемся, что представляет 
собой это произведение и почему размер буферов «правильный». 

Вы уже несколько раз встречались с периодом кругового обращения (КТТ). 
Это время, которое требуется пакету на «путешествие» от одного хоста на другой 
и обратно. Оно и представляет собой множитель «задержки», поскольку опреде- 
ляет время между моментом отправки пакета и подтверждением его получателем. 
Обычно ВТТ измеряется в миллисекундах. 

Другой множитель в произведении - полоса пропускания (Бата). Это ко- 
личество данных, которое можно передать в единицу времени по данному физи- 
ческому носителю. 


Примечание Технически это не совсем корректно, но этот термин уже дав- 
но используется. 


Полоса пропускания измеряется в битах в секунду. Например, для сети Еегпей 
полоса пропускания (чистая) равна 10 Мбит/с. 

Произведение полосы пропускания на задержку ВУ/Ш вычисляется по фор- 
муле: 


ВИР = Бапамлаев х втт. 
Если КТТ выражается в секундах, то единица измерения ВУ’ будет следу- 
ющей: 


бит 
ВИр = ————_ Х секунда = бит. 
секунда 


Если представить коммуникационный канал как «трубу», то произведение 
полосы пропускания на задержку — это объем трубы в битах (рис. 3.15), то есть 
количество данных, которые могут находиться в сети в любой момент времени. 
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ВМ! 


+ 


НИС О 


Рис. 3.15 Труба емкостью ВУИ бит 


А теперь представим, как выглядит эта труба в установившемся режиме (пос- 
ле завершения алгоритма медленного старта) при массовой передаче данных, за- 
нимающей всю доступную полосу пропускания. Отправитель слева на рис. 3.16 
заполнил трубу ТСР-сегментами и должен ждать, пока сегмент п покинет сеть. 
Только после этого он сможет послать следующий сегмент. Поскольку в трубе на- 
ходится столько же сегментов АСК, сколько и сегментов данных, при получении 
подтверждения на сегмент п - 8 отправитель может заключить, что сегмент п по- 
кинул сеть. 

Это иллюстрирует феномен самосинхронизации (зе -сосЕ1тв ргорегёу) ТСР- 
соединения в установившемся режиме []асозоп 1988]. Полученный сегмент АСК 
служит сигналом для отправки следующего сегмента данных. 


п+7 п+6 п+5 п+4 п+3 п+2 п+1 п 


Данные Данные 


АСК$ —— АСК$ 


АСК АСК АСК АСК АСК АСК АСК АСК 
п-8 п-7 п-6 п-5 п-4 п-3 п-2 п-1 


Рис. 3.16. Сеть в установившемся режиме 


Примечание Этот механизм часто называют АСК-таймером (АСК сЮСсЕ). 


Если необходимо, чтобы механизм самосинхронизации работал и поддержи- 
вал трубу постоянно заполненной, то окно передачи должно быть достаточно ве- 
лико для обеспечения 16 неподтвержденных сегментов (отп —8 доп +7). Это озна- 
чает, что буфер передачи на вашей стороне и буфер приема на стороне получателя 
должны иметь соответствующий размер для хранения 16 сегментов. В общем слу- 
чае необходимо, чтобы в буфере помещалось столько сегментов, сколько находит- 
ся в заполненной трубе. Значит, размер буфера должен быть не меньше произве- 
дения полосы пропускания на задержку. 

Выше было отмечено, что это правило не особенно полезно. Причина в том, что 
обычно трудно узнать величину этого произведения. Предположим, что вы пишете 
приложение типа ЕТР. Насколько велики должны быть буферы приема и передачи? 
Во время написания программы неясно, какая сеть будет использоваться, а поэтому 
неизвестна и ее полоса пропускания. Но даже если это можно узнать во время выпол- 
нения, опросив сетевой интерфейс, то остается еще неизвестной величина задержки. 
В принципе, ее можно оценить с помощью какого-нибудь механизма типа р1 по, но, 
скорее всего, задержка будет варьироваться в течение существования соединения. 


РТ В ВОИ ШИ ШИН — Создание эффективных сетевых программ 


Прамечание Одно из возможных решений этой проблемы предложено в ра- 
боте [5етЁе её а/.]. Оно состоит в динамическом изменении раз- 
меров буферов. Авторы замечают, что размер окна перегрузки 
можно рассматривать как оценку произведения полосы пропус- 
кания на задержку. Подбирая размеры буферов в соответствии 
с текущим размером окна перегрузки (конечно, применяя подхо- 
дящее демпфирование и ограничения, обеспечивающие справед- 
ливый режим для всех приложений), они сумели получить очень 
высокую производительность на одновременно установленных 
соединениях с разными величинами ВИО. К сожалению, такое 
решение требует изменения в ядре операционной системы, так 
что прикладному программисту оно недоступно. 


Как правило, размер буферов назначают по величине, заданной по умолчанию 
или большей. Однако ни то, ни другое решение не оптимально. В первом случае 
может резко снизиться пропускная способность, во втором, как сказано в работе 
[Зетке еб а|. 1998], — исчерпаны буферы, что приведет к сбою операционной сис- 
темы. 

В отсутствии априорных знаний о среде, в которой будет работать приложе- 
ние, наверное, лучше всего использовать маленькие буферы для интерактивных 
приложений и буферы размером 32-64 Кб — для приложений, выполняющих мас- 
совую передачу данных. Однако не забывайте, что при работе в высокоскоростных 
сетях следует задавать намного больший размер буфера, чтобы использовать всю 
доступную полосу пропускания. В работе [МаЁБ ау 1997] приводятся некоторые 
рекомендации по оптимизации настройки стеков ТСР/ТР. 

Есть одно правило, которое легко применять на практике, позволяющее по- 
высить общую производительность во многих реализациях. В работе [Сотег ап4 
Пл 1995] описывается эксперимент, в ходе которого два хоста были соединены 
сетью Ефегпе в 10 Мбит и сетью АТМ в 100 Мбит. Когда использовался размер 
буфера 16 Кб, в одном и том же сеансе ЕТР была достигнута производительность 
1,313 Мбит/с для Ефегпе{ и только 0,322 Мбит/с для АТМ. 

В ходе дальнейших исследований авторы обнаружили, что размер буфера, ве- 
личина МТО (максимальный размер передаваемого блока), максимальный размер 
сегмента ТСР (М55) и способ передачи данных уровню ТСР от слоя сокетов вли- 
яли на взаимодействие алгоритма Нейгла и алгоритма отложенного подтвержде- 
ния (совет 24). 


Примечание МТИ (максимальный блок передачи) — это максимальный размер 
фрейма, который может быть передан по физической сети. Для 
ЕбйетеЕ эта величина составляет 1500 байт. Для сети АТМ, 
описанной в работе [Сотет апа [ап 1995], - 9188 байт. 


Хотя эти результаты были получены для локальной сети АТМ и конкретной 
реализации ТСР (5ипО$ 4.1.1), они применимы и к другим сетям и реализациям. 
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Самые важные параметры: величина МТО и способ обмена между сокетами 
и ТСР, который в большинстве реализаций, производных от ТСР один и тот же. 

Авторы нашли весьма элегантное решение проблемы. Его привлекательность 
в том, ЧТО изменять надо только размер буфера передачи, а размер буфера приема 
не играет роли. Описанное в работе [Сотег ап4 Гла 1995] взаимодействие не имеет 
места, если размер буфера передачи, по крайней мере, в три раза больше, чем М$$. 


Влияние размеров буферов 


Примечание Смысл этого решения в том, что получателя вынуждают по- 
слать информацию об обновлении окна, а, значит, и АСК, предот- 
вращая тем самым откладывание подтверждения и нежелатель- 
ную интерференцию с алгоритмом Нейгла. Причины обновления 
информации о размере окна, различны для случаев, когда буфер 
приема меньше или больше утроенного М55, но в любом случае 
обновление посылается. 


Поэтому неинтерактивные приложения всегда должны устанавливать буфер 
приема не менее чем 3 Х М$$. Вспомните совет 7, где сказано, что это следует де- 
лать до вызова 1156 еп или соппесе. 


Резюме 


Производительность ТСР в значительной степени зависит от размеров буфе- 
ров приема и передачи (совет 36). В этом разделе вы узнали, что оптимальный раз- 
мер буфера для эффективной передачи больших объемов данных равен произведе- 
нию полосы пропускания на задержку, но на практике это наблюдение не особенно 
полезно. 

Хотя правило произведения применять трудно, есть другое, намного проще. 
Ему и рекомендуется всегда следовать: размер буфера передачи должен быть, по 
крайней мере, в три раза больше, чем М$$. 
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Совет 33. Используйте утилиту ртд 


Один из самых главных и полезных инструментов отладки сетей и работаю- 
щих в них приложений - это утилита р1пад. Ее основное назначение -— проверить 
наличие связи между двумя хостами. 

Прежде необходимо разъяснить несколько моментов, касающихся р1па. Во-пер- 
вых, по словам Майка Муусса, слово «р» не расшифровывается как «раске т(егпей 
ргорег» (проводящий межсетевые пакеты). Своим названием эта программа обязана 
звуку, который издает сонар, устанавливаемый на подводных лодках. История созда- 
ния программы р1па изложена в статье «Тре Зюогу оЁ Фе Раф Ргоргат» Муусса на 
М/еБ-странице БИф://Йр.а| и /-пике/рше/вит. Там же приведен и ее исходный текст. 

Во-вторых, эта утилита не использует ни ТСР ни ОШР поэтому для нее нет 
никакого хорошо известного порта. Для проверки наличия связи р1па пользуется 
функцией эхо-контроля, имеющейся в протоколе [СМР. Помните (совет 14), что, 
хотя сообщения [СМР передаются в [1Р-датаграммах, [СМР считается не отдель- 
ным протоколом, а частью ТР. 


Примечание В ВЕС 792 [Розе 1981] на первой странице сказано: <«1СМР исполь- 
зует базовую поддержку [Р, как если бы это был протокол более вы- 
сокого уровня, однако в действительности 1СМРявляется неотьем- 
лемой частью ГР и должен быть реализован в каждом [1Р-модуле>. 


Таким образом, структура пакета, посылаемого р1 пд, имеет такой вид, как на 
рис. 4.1. Показанная на рис. 4.2 [СМР-часть сообщения состоит из восьмибайтно- 
го [СМР-заголовка и п байт дополнительной информации. 


я Эхо-сообщение запрос/ответ 
для протокола |СМР 
20 байт 8-+п байт 


Рис. 4.1. Формат пакета ртд 


Обычно в качестве значения п — числа дополнительных байтов в пакете р1пд — 
выбирается 56 (МХ) или 32 (\\Мп4до\з), но эту величину можно изменить с по- 
мощью флагов -з (МХ) или -1 (УЛп9о\$). 

В некоторых версиях р1па пользователь может задавать значения дополнитель- 
ных данных или даже указывать, что они должны генерироваться псевдослучайным 
образом. По умолчанию в большинстве версий дополнительные данные - это цик- 
лически переставляемый по кругу набор байтов. 


Используйте утилиту рй9 ЕТ 1 249. 


Примечание Задание конкретных данных бывает полезно при отладке оши- 
бок, зависящих от данных. 


ОМГХ-версия р1па помещает временной штамп (структуру Е 1теуа1) в первые 
восемь байт дополнительных данных (при условии, конечно, что пользователь не 
задал меньшее количество). Когда программа р1па получает эхо-ответ, она исполь- 
зует этот временной штамп для вычисления периода кругового обращения (КТТ). 
УЛп4о\з-версия р1па этого не делает (вывод основан на анализе информации, по- 
лученной с помощью программы Е срдитр), но в тексте примера р1 пд, поставляемо- 
го в составе компилятора У1зца! С++, этот алгоритм присутствует. 


0 78 15 16 31 


Тип Код 
Идентификатор Порядковый номер 


Дополнительные данные 


Рис. 4.2. Пакет эхо-сообщения запрос/ответ протокола [СМР 


Поскольку поля идентификатор и порядковый номер не задействованы ни 
в эхо-запросе, ни в эхо-ответе, р1па использует их для идентификации получен- 
ных [СМР-ответов. Так как для [Р-датаграмм нет специального порта, они достав- 
ляются каждому процессу, который открыл простой (га\) сокет с указанием про- 
токола {СМР (совет 40). Поэтому р1па помещает свой идентификатор процесса в поле 
идентификатор, так что каждый запущенный экземпляр способен отличить отве- 
ты на свои запросы. Таким образом, поле идентификатор в этом случае можно 
представить как аналог номера порта. 

Таким же образом р1па помещает в поле порядковый номер значение счетчика 
для того, чтобы связать ответ с запросом. Именно это значение р1пд показывает 
как 1спр_зеа. 

Обычно первое ваше действие при пропадании связи с удаленным хостом - это 
запуск р1п9а с указанием адреса этого хоста (хост «пингуется»). Предположим, что 
нужно связаться с хостом А с помощью программы Ее1пе*, но соединение не 
устанавливается из-за истечения тайм-аута. Причин может быть несколько: про- 
блема в сети между двумя хостами, не работает сам хост А, проблема в удаленном 
стеке ТСР/ТР или не запущен сервер се1пе+. 

Сначала следует проверить, «пингуя» хост А, что он достижим. Если работа 
р1п9 проходит нормально, то можно сказать, что с сетью все в порядке, а проблема, 
вероятно, связана с самим хостом А. Если же невозможно «достучаться» до хоста А 
с помощью р!ла, то требуется «пропинговать» ближайший маршрутизатор, чтобы 
понять, удается ли достичь хотя бы границы собственной сети. Если это получается, 
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то воспользуйтесь программой кгасегоцее (совет 35), чтобы выяснить, насколько 
далеко можно продвинуться по маршруту от вашего хоста к хосту А. Часто это 
помогает идентифицировать сбойный маршрутизатор или хотя бы сделать пред- 
положение о месте возникновения ошибки. 

Поскольку р1пд работает на уровне протокола ТР, она не зависит от правиль- 
ности конфигурации ТСР или ОШР Поэтому иногда полезно «пропинговать» свой 
собственный хост, чтобы проверить правильность установки сетевого программ- 
ного обеспечения. Сначала можно указать р1пд возвратный адрес 1оса1Ноз& 
(127.0.0.1), чтобы убедиться в работе хотя бы части сетевой поддержки. Если при 
этом проблем не возникает, то следует «пропинговать» один или несколько сете- 
вых интерфейсов и удостовериться, что они правильно сконфигурированы. 

Попробуйте «пропинговать» хост пеёсоп4 .пеёсом. сот, который находится 
от вас в десяти переходах (рис. 4.3). 


Ьза: $ р1па пеЕсоп4.пебсом. сом 

РТМС пебсом4.пебсом. сом (199.183.9.104): 56 Заба Бусез 

64 Бугез Егом 199.183.9.104: 1спр_зеа=0 Е61=245 $1пе=598.554 мз 
64 БуЕез Егом 199.183.9.104: 1спр_зеа=1 Е&1=245 Е1те=550.081 тмз 
64 Бугез Егом 199.183.9.104: 1стр_зеа=2 &61=245 Е1пе=590.079 м5 
64 Бугез Егом 199.183.9.104: 1спр_зеа=3 6&1=245 611е=530.114 мз 
64 Бугсез Ехгош 199.183.9.104: 1спр_зеа=5 Е61=245 Е1ме=480.137 тз 
64 Бугез Егом 199.183.9.104: 1сир_зеа=6 ЕЕ1=245 Е11е=540.081 шв 
64 БуЕкез Егом 199.183.9.104: 1спр_зеа=7 Е61=245 $11е=580.084 пз 
64 Бубез Егом 199.183.9.104: 1сир_зеа=8 Е61=245 Е1ме=490.078 тв 
64 Бубсез Ехгом 199.183.9.104: 1спр_зеа=9 Е61=245 Е1те=560.090 мз 
64 Бугез Ехгом 199.183.9.104: 1спр_зеа=10 Е61=245 Е1те=490.090 мз 
^С завершили р1пд9 вручную 

— — — пебсом4.пеесом.сом рзпа з6ае1$61с8 -— - -— 

12 раскеЕз Егапзи1ЕСеЯ, 10 раскеЕз гесе1уеа, 16% раскее 1о55 
хоцпЯ-Ег1р и1п/ауч/пах/зЕЯеу = 480.137/540.939/598.554/40.871 мз 
Ьза: $ 


©ююююоююююоо°ю 


Рис. 4.3. Короткий прогон ртд 


Прежде всего, КТТ для разных пакетов мало меняется и остается в пределах 
500 мс. Как следует из последней строки, ВТТ модифицируется в диапазоне от 
480,137 мс до 598,554 мс со стандартным отклонением 40,871 мс. Текст слишком 
рано прерван, чтобы можно было сделать какие-то выводы, но и при более дли- 
тельном прогоне (около 2 мин) результат существенно не изменится. Так что мож- 
но предположить, что нагрузка на сеть постоянная. Значительный разброс ВТТ — 
это, как правило, признак изменяющейся загрузки сети. При повышенной загруз- 
ке возрастает длина очереди в маршрутизаторе, а вместе с ней — и ВТТ. При 
уменьшении загрузки очередь сокращается, что приводит к уменьшению ВТТ. 

Далее из рис. 4.3 видно, что на эхо-запрос {СМР с порядковым номером 4 не при- 
шел ответ. Это означает, что запрос либо ответ был потерян одним из промежуточных 
маршрутизаторов. По данным сводной статистики, было послано 12 запросов (0-11) 
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и получено лишь 10 ответов. Один из пропавших ответов имеет порядковый 
номер 4, второй - 11 (вероятно, он был засчитан как пропавший, поскольку не во- 
время прервана работа р1па). 


Резюме 


Утилита р1па - это один из важнейших инструментов тестирования связи 
в сети. Поскольку для ее работы требуется лишь функционирование самых ниж- 
них уровней сетевых служб, она полезна для проверки связи в условиях, когда сер- 
висы более высокого уровня, такие как ТСР, или программы прикладного уровня 
типа $ е1пеё не работают. 

С помощью р1 пад часто удается сделать выводы об условиях в сети, наблюдая 
за значениями и дисперсией КТТ и за числом потерянных ответов. 


Совет 34. Используйте программу *{срдитр 
или аналогичное средство 


Из всех имеющихся в нашем распоряжении мощных и полезных средств от- 
ладки сетевых приложений и поиска неисправностей в сети наиболее интересны 
сетевые анализаторы (их еще называют сниферами). Традиционно сетевой анали- 
затор — дорогое специализированное устройство, но современные рабочие станции 
вполне способны выполнять их функции в рамках отдельного процесса. 

Сегодня сниферы есть для большинства сетевых операционных систем. Ино- 
гда в операционную систему входит снифер, предлагаемый поставщиком (програм- 
ма эпоор в 50[а11$ или программы 1рЕгасе/ 1ргероге в А[Х), а иногда пользуются 
программами третьих фирм, например Е ср@ипр. 

Из инструментов, предназначенных только для диагностики, сниферы постепен- 
но превратились в средства для исследований и обучения. Например, они постоянно 
используются для изучения динамики и взаимодействий в сетях. В книгах [5беуепз 
1994, З{еуепз 1996] рассказано, как использовать Е сраиир, чтобы разобраться в рабо- 
те сетевых протоколов. Наблюдая за данными, которые посылает протокол, вы може- 
те глубже понять его функционирование на практике, а заодно увидеть, когда некото- 
рая конкретная реализация работает не в соответствии со спецификацией. 

В этом разделе будет рассмотрена утилита Есраипр. Как уже отмечалось, есть 
и другие программно реализованные сетевые анализаторы. Некоторые из них луч- 
ше форматируют выходные данные, но у Еср@ипр есть одно неоспоримое преиму- 
щество — она работает практически во всех (МХ-системах и в УЛпдо\уз. Поскольку 
исходные тексты Есраитр опубликованы, ее можно при необходимости адаптировать 
для специальных целей или перенести на новую платформу. 


Код Есраитр вы можете найти на сайте Бёр://м\м\м-пгр.ее.[Ы.зоу/отя. ВЫ, 


а исходные тексты и исполняемый код для УЛп4о\$ И1притр — Бр://пеёегочр- 
зегуроШюо.1/мтаитр. 
Как работает «раитр 


Посмотрим, как работает программа Е срёипр и на каком уровне протоколов она 
перехватывает пакеты. Как и большинство сетевых анализаторов, Есраитр состоит 
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из двух компонент: первая работает в ядре и занимается перехватом и, возможно, 
фильтрацией пакетов, а вторая действует в адресном пространстве пользователя 
и определяет интерфейс пользователя, а также выполняет форматирование и филь- 
трацию пакетов, если последнее не делается ядром. 

Пользовательская компонента Е сраиир взаимодействует с компонентой в яд- 
ре при помощи библиотеки 11ъ5рсар (библиотека для перехвата пакетов), кото- 
рая абстрагирует системно-зависимые детали общения с канальным уровнем сте- 
ка протоколов. Например, в системах на основе ВО 11Ьрсар взаимодействует 
с пакетным фильтром ВЗР (ВЗР расКеё Н(ег - ВРЕ) [МсСаппе ап4 ]асобзоп 
1993]. ВРЕ исследует каждый пакет, проходящий через канальный уровень, и со- 
поставляет его с фильтром, заданным пользователем. Если пакет удовлетворяет 
критерию фильтрации, то его копия помещается в выделенный ядром буфер, ко- 
торый ассоциируется с данным фильтром. Когда буфер заполняется или истека- 
ет заданный пользователем тайм-аут, содержимое буфера передается приложению 
с помощью 11Брсар. 

Этот процесс изображен на рис. 4.4. Показано, как Е сраитр и любая другая 
программа считывают необработанные пакеты с помощью ВРЕ атакже изображе- 
но еще одно приложение, читающее данные из стека ТСР/ТР, как обычно. 


Примечание Хотя на этом рисунке и Есраитр, и программа используют 
библиотеку 11Ьрсар, можно напрямую общаться с ВРЕили иным 
интерфейсом, о чем будет сказано ниже. Достоинство 11Брсар 
в том, что она предоставляет системно-независимые средства 
доступа к необработанным пакетам. В настоящее время эта би- 
блиотека поддерживает ВРЕ. интерфейс канального провайдера 
(аща [тЁ ртолаег 1теграсе — РЕРГ; систему бипО$ МПТ; потоко- 
вую МТ; сокеты типа 5ОСК_РАСКЕТ, применяемые в системе 
Гапих; интерфейс зпоор (ИХ) и разработанный в Стэнфоро- 
ском университете интерфейс епеё. В дистрибутив И1пРитр 
входит также версия 11Ьрсар для Утаоц5. 


Обратите внимание, что ВРЕ перехватывает сетевые пакеты на уровне драйвера 
устройства, то есть сразу после того, как они считаны с носителя. Это не то же самое, 
что чтение из простого сокета. В ситуации с простым сокетом вы получаете ГР-датаг- 
раммы, уже обработанные уровнем ГР и переданные непосредственно приложению, 
минуя транспортный уровень (ТСР или ОПР). Об этом рассказывается в совете 40. 

Начиная с версии 2.0, архитектура \1пРицтр очень напоминает используемую 
в системах В5О. Эта программа пользуется специальным №МП[5-драйвером (МОГ$ - 
МесмогЕ Оиуег Ицегасе Зрес!саНоп — спецификация стандартного интерфейса 
сетевых адаптеров), предоставляющим совместимый с ВРЕ фильтр и интерфейс. 
В архитектуре \1притр МОГ$-драйвер фактически представляет собой часть сте- 
ка протоколов, но функционирует он так же, как показано на рис. 4.4, только надо 
заменить ВРЕ на пакетный драйвер МП]$. 
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Рис. 4.4. Перехват пакетов с помощью ВРЕ 


Другие операционные системы используют несколько иные механизмы. В сис- 
темах, производных от ЗУ КА, для доступа к простым сокетам применяется интер- 
фейс ОЕРГ [Ох Пиегпайопа] 1991]. ОГ.Р1 - это не зависящий от протокола, ос- 
нованный на системе ЗТВЕАМ$ [Висые 1984] интерфейс к канальному уровню. 
С помощью ОГЕРГ можно напрямую получить доступ к канальному уровню, но 
по соображениям эффективности обычно вставляют в поток ЗТКЕАМ5$-модули 
рЕтоа и раЕтоа. Модуль БаЁтоа предоставляет услуги по буферизации сообще- 
ний и увеличивает эффективность за счет ограничения числа контекстных пере- 
ключений, требуемых для доставки данных. 


Примечание Это аналогично чтению полного буфера из сокета вместо по- 
байтного чтения. 


Модуль рЁЕтоа - это фильтр, аналогичный ВРЕ Поскольку он несовместим 
с фильтром ВРЕ Есрдипр вставляет этот модуль в поток, а фильтрацию выполня- 
ет в пространстве пользователя. Это не столь эффективно, как при использовании 
ВРЕ так как в пространство пользователя приходится передавать каждый пакет, 
даже если он не нужен программе Е сраипр. 
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На рис. 4.5 показаны Есраитр без модуля рЁтод и приложение, которое получает 
необработанные пакеты с использованием находящегося в ядре фильтра. 

На рис. 4.5 также представлены приложения, пользующиеся библиотекой 
11Ьрсар, но, как и в случае ВРЕ это необязательно. Для отправки сообщений непо- 
средственно в поток и получения их обратно можно было бы воспользоваться вызо- 
вами деетза и риетз9. Книга [Каро 1993] — отличный источник информации о про- 
граммировании системы 5ТКЕАМ$, ОГ.Р! и системных вызовах деетза и ра тза. 
Более краткое обсуждение вопроса можно найти в главе 33 книги [З{еуепз 1998]. 
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Рис. 4.5. Перехват пакетов с помощью ОЁР! 


Наконец, есть еще и архитектура Ппих. В этой системе доступ к необработанным 
сетевым пакетам производится через интерфейс сокетов типа $ОСК_РАСКЕТ. Для 
использования этого простого механизма надо открыть подобный сокет, при- 
вязать к нему требуемый сетевой интерфейс, включить режим пропускания всех 
пакетов (ргог15сиои$ то4е) и читать из сокета. 


Примечание Начиная с версии 2.2 ядра [лпих, рекомендуется несколько дру- 


гой интерфейс, но последняя версия 11Ьрсар по-прежнему под- 
держивает описанный выше. 


Программа 1срдитр ИТГ 1 255, 


Например, строка 
3 = зоскее( АЕ_ТМЕТ, 5ОСК_РАСКЕТ, ЮЕопз( ЕТН_Р_ А], ) }); 


открывает сокет, предоставляющий доступ ко всем Еегпе-пакетам. В качестве 
третьего параметра можно также указать ЕТН_Р_ТР (пакеты ГР), ЕТН_Р_ТРУб (па- 
кеты [Руб) или ЕТН_Р_АКБР (пакеты АКР). Будем считать, что этот интерфейс ана- 
логичен простым сокетам ($0Ск_ВАМ), только доступ производится к канальному, 
а не сетевому (ТР) уровню. 

К сожалению, несмотря на простоту и удобство этого интерфейса, он не очень 
эффективен. В отличие от обычных сокетов, ядро в этом случае не осуществляет 
никакой буферизации, так что каждый пакет доставляется приложением сразу 
после поступления. Отсутствует также фильтрация на уровне ядра (если не счи- 
тать параметра ЕТН_Р_*). Поэтому фильтровать приходится на прикладном уров- 
не, а это означает, что приложение должно получать все пакеты без исключения. 


Использование {«р4итр 


Прежде всего для использования Е ср@ипр надо получить разрешение. Посколь- 
ку применение сетевых анализаторов небезопасно, по умолчанию Еср@итр кон- 
фигурируется с полномочиями суперпользователя гоой. 


Примечание К системе Ут4ои5 это не относится. Коль скоро МОГ5-драй- 
вер для перехвата пакетов установлен, воспользоваться про- 
граммой иИ1притр может любой. 


Во многих случаях лучше дать возможность всем пользователям работать 
с программой Е сраипр, не передавая им полномочия суперпользователя. Это де- 
лается по-разному, в зависимости от версии МХ и документировано в руковод- 
стве по Е срдипр. В большинстве случаев надо либо предоставить всем права на 
чтение из сетевого интерфейса, либо сделать Есраиир зейи!4-программой. 

Проще всего вызвать Еср@лтр вообще без параметров. Тогда она будет пере- 
хватывать все сетевые пакеты и выводить о них информацию. Однако полезнее 
указать какой-нибудь фильтр, чтобы видеть только нужные пакеты и не отвле- 
каться на остальные. Например, если требуются лишь пакеты, полученные от хо- 
ста Ъза или отправленные ему, то можно вызвать Е ср@иир так: 


Есрацир Позё за 


Если же нужны пакеты, которыми обмениваются хосты Ъ34 и зрагс, то мож- 
но использовать такой фильтр: 


ПозЕ Ьз@Я апЯ НозЕ врагс 
ИЛИ сокращенно -— 
Нозс Бза ап зрагс 


Язык для задания фильтров достаточно богат и позволяет фильтровать, на- 
пример, по следующим атрибутам: 
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о протокол; 

О хост отправления и/или назначения; 

о сеть отправления и/или назначения; 

о Ефегпе-адрес отправления и/или назначения; 

О порт отправления и/или назначения; 

О размер пакета; 

о пакеты, вещаемые на всю локальную сеть или на группу (как в Еегпев, так 
ив[Р); 

О пакет, используемый в качестве шлюза указанным хостом. 


Кроме того, можно проверять конкретные биты или байты в заголовках про- 
токолов. Например, чтобы отбирать только ТСР-сегменты, в которых выставлен 
бит срочных данных, следует использовать фильтр 


Сср[Г 13 ] & 16 


Чтобы понять последний пример, надо знать, что четвертый бит четырнадца- 
того байта заголовка ТСР - это бит срочности. 

Поскольку разрешается использовать булевские операторы апа@ (или &&), ог 
(или ||) ипоеё (или !) для комбинирования простых предикатов, можно задавать 
фильтры произвольной сложности. Ниже приведен пример фильтра, отбирающе- 
го [СМР-пакеты, приходящие из внешней сети: 


1спр ап@Я поЕ згс пеб 1оса]пеё 


Примеры более сложных фильтров рассматриваются в документации по Есрдипр. 


Выходная информация, формируемая «раитр 


Информация, выдаваемая программой Есрдипр, зависит от протокола. Рас- 
смотрим несколько примеров, которые помогут составить представление о том, 
что можно получить от Есраипр для наиболее распространенных протоколов. До- 
кументация, поставляемая вместе с программой, содержит исчерпывающие све- 
дения о формате выдачи. 

Первый пример - это трассировка сеанса по протоколу ЗМТР (Заре Май Тгапз- 
{ег Ргобосо] — простой протокол электронной почты), то есть процедура отправки элек- 
тронного письма. Распечатка на рис. 4.6 в точности соответствует выдаче Еср@иир — 
только добавлены номера строк, напечатанные курсивом, удалено имя домена хос- 
та Ьза и перенесены длинные строки, не уместившиеся на странице. 

Для получения трассировки послано письмо пользователю с адресом в домене 
асе .пек. Таким образом, адрес имел вид изег@ асе. пек. 

Строки 1—4 относятся к поиску адреса ЗМТР-сервера, обслуживающего домен 
асе.пек. Это пример выдачи, генерируемой Е ср@ипр для запросов и ответов сер- 
виса ОМ5. В строке 1 Ъза запрашивает у сервера имен своего сервис-провайдер 
(п31.1х.пеЕсом. сом) имя или имена почтового сервера аее.пек. В первом поле 
находится временной штамп пакета (12:54:32.920881). Поскольку разрешающая 
способность таймера на машине ъза составляет 1 мкс, показано шесть десятичных 
знаков. Вы видите, что пакет ушел из порта 1067 на рза в порт 53 (Яота1 п) на ма- 
шине пз1. Далее, дается информация о данных в пакете. Первое поле (45801) — 
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1 12: 


2 12: 


3 12: 


4 12: 


5 12: 


[®%) 
- 
|5) 


24 12: 


ро ВН 


26 12: 


И 


28 12: 


54:32.920881 Ъ5а.1067 > пз1.1х.пебсом. сом. аота1т: 
45801+ МХ? чее.пеб. (25) 

54:33.254981 п51.1х.пебсом. сом. @аота1т > Ьза.1067: 
45801 5/4/9 (371) (ОЕ) 

54:33.256127 Ьза.1068 > п51.1х.пебсом.сом.аота1т: 
45802+ А? шЕарор2.дее.пеб. (33) 

54:33.534962 п51.1х.пеЕсом.сом.@Яотмта1т > 54.1068: 
45802 1/4/4 (202) (ПЕ) 

54:33.535737 Ьза.1059 > шЕарор2.дее.пее. змёр: 

$ 585494507:585494507 (0) м1п 16384 

<п$$5 1460, пор, изса1е 0, пор, пор, 

Е1тезбатр 6112 0> (ПЕ) 


:54:33.784963 шЕарор2.чЕе.пее.зшёр > Ьза.1059: 


$ 1257159392:1257159392 (0) асКк 585494509 м1п 49152 
<п$$ 1460, пор, изса1е 0, пор, пор, 
Е1мезбашр 7853753 6112> (БР) 


:54:33.785012 Ь3а.1059 > шЕарор2.дее.пеб. зтёЕр: 


аск 1 им1п 17376 «пор, пор, 
С1тезбсатр 6112 7853753> (ОР) 


:54:34.235066 шЕарор2.чЕе.пеЕ.змер > $а.1059: 


Р 1:109 (108) аск 1 м1 49152 
<пор, пор, 1тезбатр 7853754 6112> (РЕ) 


:54:34.235277 Ьза.1059 > шЕарор2 .д%е.пеф. зтёЕр: 


Р 1:19(18) асКк 109 и1п 17376 

<пор, пор, Е1тезбатр 6113 7853754> (ПЕ) 
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54:36.675105 Ъза.1059 > шёЕарор2.дЕе.пек. змёр; 

Г 663:663 (0) асКкК 486 м1п 17376 

<пор, пор, Е1тезбатр 6118 7853758> (ОЕ) 

54:36.685080 шЕарор2.чЕе.пее.зтёр > Ьза.1059: 

Е 486:486(0) асКк 663 м1 49152 

<пор, пор, Е 1тезбатшр 7853758 6117> (ОР) 

54:36.685126 Ь5а.1059 > шЕарор2.д%Ее.пек. эзтёр: 
аск 487 и1п 17376 

<пор, пор, (1тезбсатр 6118 7853758> (БЕ) 

54:36.934985 шЕарор2.ч6е.пее.зтЕёр > Ьза.1059: 

Е 486:486(0) аск 664 м1п 49152 

<пор, пор, Е1пезеатр 7853759 6118> (ПЕ) 

54:36.935020 Ь5а.1059 > шЕарор2.а%е.пеф. змЕр: 
аск 487 м1п 17376 

<пор, пор, Е1тезбатр 6118 7853759> (ПЕ) 


Рис. 4.6. Трассировка ЗМТР-сеанса с включением обмена по протоколам ОМ№$ и ТСР 


это номер 


запроса, используемый функциями разрешения имен на Ъза для сопо- 


ставления ответов с запросами. Знак «+» означает, что функция разрешения задает 
опрос О№5-сервером других серверов, если у него нет информации об ответе. Стро- 


ка «МХ?» 


показывает, что это запрос о записи почтового обмена для сети, имя ко- 


торой стоит в следующем поле (чЕе.пеЕ). Строка «(25)» свидетельствует о том, 
что длина запроса — 25 байт. 
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Строка 2 - это ответ на запрос в строке 1. Число 45801 - это номер запро- 
са, к которому относится ответ. Следующие три поля, разделенные косой чер- 
той, — количество записей в ответе, записей от сервера имен (полномочного аген- 
та) и прочих записей. Строка «(371)» показывает, что ответ содержит 371 байт. 
И, наконец, строка «(ОЕ)» означает, что в [Р-заголовке ответа был поднят бит 
«Воп’ артег&» (не фрагментировать). Итак, эти две строки иллюстрируют ис- 
пользование системы ОМ для поиска обработчиков почты (об этом кратко упо- 
миналось в совете 29). 

Если в двух первых строках было выяснено имя обработчика почты для сети 
дЕе.пеф, то в двух последующих выясняется егоПрограмма {ср4итр [Р-адрес. 
«А?» в строке 3 указывает, что это запрос 1Р-адреса хоста пЕарор2 .дЕе.пек- од- 
ного из почтовых серверов компании СТЕ. 

Строки 5-28 содержат детали обмена по протоколу ЗМТР. Процедура трех- 
стороннего квитирования между хостами Ь54 и пеарор2 начинается в строке 5 
и заканчивается строкой 7. Первое поле после временного штампа и имен хостов -— 
это поле Ё1ад5. «3» в строке 5 указывает, что в сегменте установлен флаг ЗУМ. 
Другие возможные значения флага: «Е» (ЕТМ), «О» (ОКС), <«Р» (РОЗН), «К» 
(В5Т) и <.> (нет флагов). Далее идут порядковые номера первого и последнего 
байтов, а за ними в скобках — число байтов данных. Эти поля могут вызвать неко- 
торое недоумение, так как «порядковый номер последнего» - это первый неис- 
пользованный порядковый номер, но только в том случае, когда в пакете есть 
данные. Удобнее всего считать, что первое число - это порядковый номер пер- 
вого байта в сегменте (ЗУМ или информационном), а второе — порядковый номер 
первого байта плюс число байтов данных в сегменте. Следует отметить, что по 
умолчанию показываются реальные порядковые номера для $УМ№-сегментов и сме- 
щения -— для последующих сегментов (так удобнее следить). Это поведение мож- 
но изменить с помощью опции -5 в командной строке. 

Во всех сегментах, кроме первого ЗУМ, имеется поле АСК, показывающее, 
какой следующий порядковый номер ожидает отправитель. Это поле (в виде аск 
ппп), как и раньше, по умолчанию содержит смещение относительно порядкового 
номера, указанного в сегменте $УМ. 

За полем АСК идет поле и1паом. Это количество байтов данных, которое го- 
тов принять удаленный хост. Обычно оно отражает объем свободной памяти в бу- 
ферах соединения. 

И, наконец, в угловых скобках указаны опции ТСР. Основные опции рассмат- 
риваются в ВЕС 793 [Розе] 19815] и ВЕС 1323 [асоБзоп её а1. 1992]. Они обсуж- 
даются также в книге [5{еуепз 1994], а их полный перечень можно найти на \Ь- 
странице Бр: //млуми1еди Лп-побезДапа/а5$1ептеп$/&ср-рагатеег. 

В строках 8-23 показан диалог между программой зепдта11 на Ьза и $МТР- 
сервером на машине мбарор2. Большая часть этих строк опущена. Строки 24-28 
отражают процедуру разрыва соединения. Сначала Ьз4 посылает ЕПМ в строке 24, 
затем приходит ЕПМ от пбарор2 (строка 25). Заметьте, что в строке 27 пкарор2 
повторно посылает ЕП. Это говорит о том, что хост не получил от за подтвержде- 
ния АСК на свой первый Е1М, иеще раз подчеркивает важность состояния Т1МЕ- 
МТА]Т (совет 22). 
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Теперь посмотрим, что происходит при обмене ОШР-датаграммами. С помо- 
щью клиента идрне11ос (совет 4) следует послать один нулевой байт в порт сер- 
вера времени дня в домене пеесом . сом: 


рза: $ чарве11ос пеёсош4.пеесош.сом ЯауЕ1те 
Три бер 16 15:11:49 1999 
за: $ 


Хост пеёсот4 возвращает дату и время в ООР-датаграмме. Программа Е срдиптр 
печатает следующее: 


18:12:23.130009 Ъ$4.1127 > песвоп4 .пеЕсом. сом. Яау®1те: чар 1 
18:12:23.389284 песбом4.пебсом. сот.ЧауЕ1те > 54.1127: пар 26 


Отсюда видно, что Ъз9 послал пессоп4 ОПР-датаграмму длиной один байт, 
а пеёсош4 ответил датаграммой длиной 26 байт. 

Протокол обмена [СМР-пакетами аналогичен. Ниже приведена трассировка 
одного запроса, генерируемого программой р1пча с хоста Ъз@ на хост пеесоп4: 


1 06:21:28.690390 Ъза > пеЁсом4 .пеЕбсом.сом: 1стр: есро кеацезе 
2 06:21:29.400433 пеЕсоп4.пеесом.сом > Ьз@: 1спшр: есбо гер1у 


Строка 1спр: означает, что это {СМР-датаграмма, а следующий за ней текст 
описывает тип этой датаграммы. 

Один из недостатков Еср@иптр — это неполная поддержка вывода собственно 
данных. Часто во время отладки сетевых приложений необходимо знать, какие 
данные посылаются. Эту информацию можно получить, задав в командной строке 
опции -$ и -х, но данные будут выведены только в шестнадцатеричном формате. 
Опция -х показывает, что содержимое пакета нужно выводить в шестнадцатерич- 
ном виде. Опция -з сообщает, сколько данных из пакета выводить. По умолчанию 
Есрацир выводит только первые 68 байт (в системе ЗипО$ МТ - 96 байт). Этого 
достаточно для заголовков большинства протоколов. Повторим предыдущий при- 
мер, касающийся ОШР, но здесь нужно выводить также следующие данные: 


Есрацир -х -$ 100 -1 


После удаления строк, относящихся к ОМ№$, и исключения имени домена из 
адреса хоста Ьза получается следующий результат: 


1 12:57:53.299924 54.1053 > пеёсом4 .пебсом. сом. Яауеае: чар 1 
4500 001а 0344 0000 4011 17а1 с7Ь7 с684 
с7Ь7 0968 041а 000а 0009 9с56 00 

2 12:57:53.558921 пеЕсоп4 .пебсом. сом. Яау& 1ме > Ьза.1053: чар 26 
4500 0036 Е0с8 0000 3611 3493 с7Ь7 0968 
с77 с684 000а 041а 0022 765а 5375 6е20 
5365 7020 3139 2030 393а 3537 3За34 3220 
3139 3939 0даоа 


Последний байт в первом пакете — это нулевой байт, который зарпве11ос посы- 
лает хосту пер сом4. Последние 26 байт второго пакета — это полученный ответ. Ин- 
терпретировать приведенные в нем шестнадцатеричные цифры довольно трудно. 
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Авторы Еср@цтр не хотели давать АЗСП-представление данных, так как 
полагали, что это упростит кражу паролей для технически неподготовленных 
лиц. Теперь многие считают, что широкое распространение программ для кра- 
жи паролей сделало это опасение неактуальным. Поэтому есть основания по- 
лагать, что в последующие версии Е сраипр будет включена поддержка вывода 
в коде АЗСИ*. 

А пока многие сетевые программисты упражняются в написании фильтров, 
преобразующих выдачу Есраипр в код АЗСП. Несколько подобных программ есть 
в [шеглеё. Показанный в листинге 4.1 сценарий Рег| запускает Есраипр, перена- 
правляет ее вывод к себе и перекодирует данные в АСИ. 


Листинг 4.1. Рей-сценарий для фильтрации выдачи {краитр 


Есра 

1 #! /азк/Ь1п/рег15 

2 бЕсрацир = "/азк/зЬ1п/Есраиир"; 

3 ореп( ТСРО, "56сраитр @АВСУ |") || 

4 а1е "не могу запустить Есраицир: \$!\\п"; 

5$| = 1; 

6 мВ11е ( <ТСРО» ) 

9-5 

8 Е 

9 { 

10 свБор; 
11 $86х = $; 

12 $з6х =- 6х / \6//а; 

13 бесх = расКк "Н*" , $56; 

14 $зЕхк =- бу/\х0-\х1Е\х7Е-\ХЕЕ/./; 

15 релпЕЕ "\6%-405\6%5\п", зибзек( $_, 4 ), $36х; 
16 } 

17 е1зе 

18 { 

19 ру1пЕ; 
20 } 

21 } 

вера 


Если еще раз прогнать последний пример, но вместо Есралир использовать 
Есра, то получится следующее: 


1 12:58:56.428052 Ъза.1056 > пебсом4 .пеесом. сот. ЯауЕ1ме: чар 1 
4500 001а 0347 0000 4011 179е с7Ь7 с684Е....... бараны 
с7Ь7 0968 041а 000а 0009 9с56 00 [ ...р. ..... $. 

2 12:58:56.717128 пебсом4А.пебссом. сом.Яауе1те > Ь$а.1053: пар 26 
4500 0036 10Е1 0000 3611 1465 с7Ь7 0968 Е..6....6..К...В 


с7Ь7 с684 000а 0420 0022 7656 5375 6е20 ....... . "ГУбип 
5365 7020 3139 2030 393а 3538 3За34 3620 Сер 19 09:58:46 
3139 3939 0аба 1999.. 


* Начиная с версии 3.5 Есраитр позволяет выводить и АЗСП-представление. Для этого надо одновре- 
менно указать опции -Х и -х - Прим. автора. 
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Резюме 


Программа Е срацлф - это незаменимый инструмент для изучения того, что про- 
исходит в сети. Если знать, что в действительности посылается или принимается «по 
проводам», то трудные, на первый взгляд, ошибки удается легко найти и исправить. 
Эта программа представляет собой также важный инструмент для исследований 
динамики сети, а равно средство обучения. В последнем качестве она широко при- 
меняется в книгах серии «ТСР/Р Цизгабе4», написанных Стивенсом. 


Совет 35. Применяйте программу 1гасегоще 


Утилита Е гасекоцее - это важный инструмент для нахождения ошибок марш- 
рутизации, изучения трафика в Пцегпе и исследования топологии сети. Как и мно- 
гие другие распространенные сетевые инструменты, Егасегоц%е была разработана 
коллективом лаборатории Лоренса Беркли в Университете Калифорнии. 


Примечание В комментариях к исходному тексту Ван Джекобсон, автор про- 
граммы ЕгасегоцЕе, пишет: «Я пытался найти ошибку в рабо- 
те алгоритма маршрутизации в течение 48 бессонных часов, 
и этот код родился как-то сам собой». 


Идея Егасегоцее проста. Программа пытается определить маршрут между 
двумя хостами в сети, заставляя каждый промежуточный маршрутизатор посы- 
лать [СМР-сообщение об ошибке хосту-отправителю. Далее об этом механизме 
будет сказано подробнее. Сначала нужно несколько раз запустить программу и по- 
смотреть, что она выдает. Проследим маршрут между хостом ЪзЯ и компьютером 
в Университете города Тампа на юге Флориды (рис. 4.7). Как обычно, перенесены 
строки, не умещающиеся на странице. 

Число слева в каждой строке — это номер промежуточного узла. За ним идет 
имя хоста или маршрутизатора в этом узле и далее - [Р-адрес узла. Если узнать 
имя не удается, то Егасегоцее печатает только [Р-адрес. Такая ситуация наблю- 
дается в узле 13. Как видно, по умолчанию программа пыталась определить имя 
хоста или маршрутизатора трижды, а три числа, следующие за 1Р-адресом, - это 
периоды кругового обращения (ВТТ) для каждой из трех попыток. Если при оче- 
редной попытке на запрос никто не отвечает или ответ теряется, то вместо време- 
Ни печатается «*». 

Хотя компьютер 2199у.изЁ.еди расположен в соседнем городе, в Циегпе 
между ними находится 14 узлов. Сначала данные проходят через два маршрутиза- 
тора в Тампе, относящихся к сети пе сом. пее (это сервис-провайдер, через которого 
рза выходит в Пицегпее), потом еще Через два маршрутизатора, а затем через марш- 
рутизатор пеесом. пеё вузле МАЕ-ЕАЗТ (узел 5) в сеть, находящуюся в Вашинг- 
тоне, округ Колумбия. Узел МАЕ-ЕАЗТ - это точка пересечения сетей, в которой сер- 
вис-провайдеры передают друг другу Пегле{-трафик. Далее покидает узел МАЕ-ЕАЗТ 
и попадает в сеть врг1п*11пк.пеё. От маршрутизатора сети ЗрииЁПоК в узле 
МАЕ-ЕА$Т он пролегает вдоль восточного побережья до домена цз Е . ед (узел 13). 
И наконец на шаге 14 маршрут подходит к компьютеру 21889. 
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Ьза: $ Екасекоцее 21а3у. ивЁ. еац 
Стасегочее бо 219ду. чзЕЁ. еац (131. 247. 1. 40), 30 Борз пах, 
40 Бусе раскеЕз 
1 сап-Е1-ри8. пебсом. пеб (163. 179. 44. 15) 
128. 960 мшз 139. 230 из 129. 483 шв 
2 саш-Е1-9м1. пебсом. пее (163. 179. 44. 254) 
139. 436 шз 129.226 шв 129.570 твз 
3 В1-0.п19-Е1-ам1 .пебсом.пее (165.236.144.110) 
279.582 шз 199.325 из 289.611 пз 
4 а5-0-0-7.маз-Яс-а\1.пебсом.пее (163.179.235.121) 
179.505 из 229.543 пшз 179.422 шв 
5 11-0.мае-еазе.пебсом.пее (163.179.220.182) 
189.258 шё 179.211 шзё 169.605 шв 
6 =1-мае-е-Е0-0.зрг1рЕ11пк.пее (192.41.177.241) 
189.999 шё 179.399 швз 189.472 тв 
7 =1-6554-ас-1-0-0.зрг1пЕ11пК.пеЕ (144.228.10.41) 
180.048 мз 179.388 шз 179.562 т5з 
8 =1-5510-х1у-2-3.врх1пЕ1]1пК.пее (144.232.7.153) 
199.433 шз 179.390 м5 179.468 пз 
9 =1-5511-к1у-9-0.зрг1пЕ11пК.пее (144.232.0.46) 
199.259 тз 189.315 шв 179.459 швз 
10 31-5510-ох1-1-0.зрг1пЕ11рк.пее (144.232.9.62) 
189.987 шз 199.508 шз 219.252 пз 
11 $1-9\м3-оЕ1-4-0-0.зрг1рЕ11пК.пее (144.232.2.154) 
219.307 шз 209.382 пз 209.502 мз 
12 $1-а$Е-1-0-0.зрх1пЕ11пКкК.пее (144.232.154.14) 
209.518 пз 199.288 пз 219.495 тз 
13 131.247.254.36 (131.247.254.36) 209.318шз 199.281тз 219.588мв 
14 2199у.чзЕ.е@а (131.247,1.40) 209.591 пз * 210.159 шв 


Рис. 4.7. Маршрут до хоста 21дду.изРеди, прослеженный 1гасегоше 


Посмотрим, как далеко от Ъз& отстоит Калифорнийский университет в Лос- 
Анджелесе. Понятно, что географически он находится на другом конце страны, 
в Калифорнии. А если выполнить $ гасегоце до хоста рапеНег в Калифорний- 
ском университете, то получится результат, показанный на рис. 4.8. 

На этот раз маршрут проходит только через 13 промежуточных узлов и дости- 
гает домена цс1а.е@ц на шаге 11. Таким образом, топологически Ьза ближе к Ка- 
лифорнийскому университету, чем к Университету на юге Флориды. 


Примечание Университет Чепмена, расположенный также вблизи Лос-Анд- 
желеса, находится всего в девяти промежуточных шагах от 
Ьза. Это связано с тем, что домен свартап . еац, как и Ьза, под- 
ключен к Гиетеё через сеть песот.пеь и весь трафик проходит 
по этой опорной сети. 


Как работает 1гасегоше 


А теперь разберемся, как работает сгасегоцее. Вспомним (совет 22), что в [Р- 
датаграмме есть поле ТТТ, которое уменьшается наединицу каждым промежуточным 
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Ьза: $ Егасекочее рапенег.св.ис1а.еачи 
Сгасегоцее Со рапЕВег.сз-чс1а.е@и (131.179.128.25), 
30 ПБор5$ шах, 40 Бубе расКее$ 
1 Еам-Е1-ри8 .пебсом.пее (163.179.44.15) 
148.957 шз 129.049 шз 129.585 пмз 
2 Еам-Е1-9и1.пебсош.пеб (163.179.44.254) 
139.435 шв 139.258 шв 139.434 шв 
3 В1-0.114а-Е1-а9\1.пебсом.рее (165.236.144.110) 
139.538 мз 149.202 шз 139.488 пшз 
4 а5-0-0-7.маз-ас-ди1 .пебсом.пее (163.179.235.121) 
189.535 шз 179.496 шз 168.699 тшз 
5 52-0.мае-еазе.пебсом.пее (163.179.136.10) 
180.040 мз 189.308 мз 169.479 пшз 
6 срез-Еаа1-0.Мазр1пабоп.си.пее (192.41.177.180) 
179.186 шз 179.368 шз 179.631 тз 
7 соге5-15516-0-0.Мазр1пабоп.сим.пее (204.70.1.21) 
199.268 шё 179.537 шв 189.694 тв 
8 согегоцеег2 .В1оош1павоп.си.пее (204.70.9.148) 
239.441 пз 239.560 шз 239.417 тшз 
9 Богаегсоге3 .В1оом1павоп.см.пее (166.48.180.1) 
239.322 из 239.348 шз 249.302 тв 
10 ис1а-1пЕехгпее-е-3.В1оом1пабоп.см.пее (166.48.181.254) 
249.989 шз 249.384 шз 249.662 тз 
11 срп5-63-1.срп.цс1а.еац (169.232.1.34) 
258.756 шз 259.370 мз 249.487 мз 
12 131.179.9.6 (131.179.9.6) 249.457 шз 259.238 шз 249.666 мз 
13 РапЕПег.С$.0СЬА.ЕРО (131.179.128.25) 259.256 шз 259.184 шв * 
Ьза: $ 


Рис. 4.8. Маршрут до хоста рап!тег.с$.ица.еди, прослеженный 1гасегоше 


маршрутизатором. Когда маршрутизатор получает датаграмму, у которой в поле 
ТТТ. находится единица (или нуль), он отбрасывает ее и посылает отправителю 
[СМР-сообщение «истекло время в пути». 

Программа Е гасегоцёе использует это свойство. Сначала она посылает по- 
лучателю ЧОР-датаграмму, в которой ТТГ. установлено в единицу. Когда дата- 
грамма доходит до первого маршрутизатора, тот определяет, что поле ТТ|. равно 
единице, отбрасывает датаграмму и посылает отправителю [СМР-сообщение. 
Так вы узнаете адрес первого промежуточного узла (из поля «адрес отправите- 
ля» в заголовке [СМР). И угасекоцее пытается выяснить его имя с помощью 
функции депозЕЪуадах. Чтобы получить информацию о втором узле, Егасегочёе 
повторяет процедуру, на этот раз установив ТТГ. равным двум. Маршрутизатор 
в первом промежуточном узле уменьшит ТТТ. на единицу и отправит датаграмму 
дальше. Но второй маршрутизатор определит единицу в поле ТТТ, отбросит да- 
таграмму и пошлет [СМР-сообщение отправителю. Повторяя эти действия, но уве- 
личивая каждый раз значение ТТТ, с гасекоцёе может построить весь маршрут 
от отправителя к получателю. 
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Рис. 4.9. Маршрутизатор М№ ошибочно переправляет 
датаграмму с ТТ, равным нулю 


Когда датаграмма с достаточно большим начальным значением ТТТГ. наконец 
доходит до получателя, ТТТ. будет равно единице, но, поскольку дальше пере- 
правлять датаграмму некуда, стек ТСР/[Р попытается доставить ее ожидающему 
приложению. Однако Егасегоцее установлено в качестве порта назначения та- 
кое значение, которое вряд ли кем-то используется, поэтому хост-получатель вер- 
нет {СМР-сообщение «порт недоступен». Получив такое сообщение, сгасегоче 
определяет, что конечный получатель обнаружен, и трассировку можно завершить. 

Поскольку протокол ОПР ненадежен (совет 1), не исключена возможность по- 
тери датаграмм. Поэтому Е гасегоцее пытается «достучаться» до каждого проме- 
жуточного хоста или маршрутизатора несколько раз, то есть посылает несколько 
датаграмм с одним и тем же значением ТТГ. По умолчанию делается три попыт- 
ки, но это можно изменить с помощью опции -ч4. 

Кроме того, Е гасехоце нужно определить, сколько времени ждать [СМР-со- 
общения после каждой попытки. По умолчанию время ожидания - 5 с, но это зна- 
чение можно изменить с помощью опции -". Если в течение этого времени [СМР- 
сообщение не получено, то вместо значения КТТ печатается звездочка (*). 

В описанном процессе могут быть некоторые трудности: +гасегоч&е полагается 
на то, что маршрутизаторы будут, как положено, отбрасывать 1Р-датаграммы, в ко- 
торых ТТТ. равно единице, и посылать при этом 1СМР-сообщение «истекло время 
в пути». К сожалению, некоторые маршрутизаторы таких сообщений не посылают, 
и тогда печатаются звездочки. Есть также маршрутизаторы, которые посылают со- 
общение, но с тем значением ТТТ, которое обнаружили во входящей датаграмме. 
Поскольку оно оказалось равным нулю, то датаграмма будет отброшена первым же 
узлом на обратном пути (если, конечно, это не случилось на первом шаге). Результат 
точно такой же, как если бы [СМР-сообщение не посылалось вовсе. 

Некоторые маршрутизаторы ошибочно переправляют далее датаграммы, в ко- 
торых ТТТ. равно нулю. Если такое происходит, то следующий маршрутизатор, 
например М + 1, отбросит датаграмму и вернет {СМР-сообщение «истекло время 
в пути». На дальнейшей итерации маршрутизатор М + 1 получит датаграмму со 
значением ТТ, равным единице, и вернет обычное {СМР-сообщение. Таким 
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образом, маршрутизатор М + 1 появится дважды: первый раз в результате ошибки 
предыдущего маршрутизатора, а второй — после корректного отбрасывания дата- 
граммы с истекшим временем работы. Такая ситуация изображена на рис. 4.9, а ее 
видимое проявление - в строках, соответствующих узлам 5 и 6 на рис. 4.10. 


Ьза: $ Егасегоц$ее зугир.р111.сом 
сгасегоцее Фо зугир.В111.согп (208.162.106.3), 
30 Борз мах, 40 Бубе расКеёз 
1 сапм-Е1-рм5.пебсом.пее (163.179.44.11) 
129.120 мз 139.263 из 129.603 шв 
2 Саш-Е1-чм1.пеесом.пее (163.179.44.254) 
129.584 шз 129.328 из 149.578 тв 
3 ,Ъ1-0.пм194-Е1-9и\1.пебсом.пее (165.236.144.110) 
219.595 м5 229.306 из 209.602 пз 
4 а5-0-0-7.маз-ас-ди1.пебсом.пее (163.179.235.121) 
179.248 из 179.521 шв 179.694 мв 
5 №2-0.мае-еаз® .пебсом.пее (163.179.136.10) 
179.274 шз 179.325 ив 179.623 ив 
6 }№2-0.мае-еазе.пебсом.пее (163.179.136.10) 
169.443 шз 199.318 шзё 179.601 тв 
7 срез-Еаа1-0.мазр1паеоп.см.пее (192.41.177.180) 189.529 шв 
согеб-зехг1а15-1-0.МазВ1паеоп.см.пее 
(204.70.1.221) 209.496 шз 209.247 пз 
8 Богаегсоге2.Возбоп.си.пеб (166.48.64.1) 
209.486 мз 209.332 из 209.598 тв 
9 Ь111-азвос1абез1пс-1пбегпее.Возбоп.см.пее (166.48.67.54) 
229.602 м5 219.510 м5 * 
10 зугир.6111.согп (208.162.106.3) 239.744 тв 239.348 м 219.607 пмв 
Ьза: $ 


Рис. 4.10. Выдача 1гасегоще с повторяющимися узлами 


На рис. 4.10 показано еще одно интересное явление. Вы видите, что в узле 7 
маршрут изменился после первой попытки. Возможно, это было вызвано тем, что 
маршрутизатор в узле 6 выполнил какие-то действия по балансированию нагрузки. 
А возможно, что узел срез-Е991-0.маз1па оп. си. пеё за время, прошедшее 
с момента первой попытки, успел «отключиться», и вместо него был использован 
маршрутизатор с адресом согеб-зег1а15-1-0.МазВ1пабоп.си.пее. 

Еще одна проблема, встречающаяся, к сожалению, все чаще, состоит в том, что 
маршрутизаторы полностью блокируют все {[СМР-сообщения. Некоторые органи- 
зации, ошибочно полагая, что {СМР-сообщения несут какую-то опасность, отключа- 
ют их. В таких условиях Егасегоцее становится бесполезной, поскольку первый же 
такой узел, встретивигийся на маршруте к получателю, с точки зрения с гасегочее 
ведет себя как «черная дыра». Никакая информация от последующих узлов не до- 
ходит, так как этот маршрутизатор отбрасывает и сообщение «истекло время 
в пути», и сообщение «порт недоступен». 

Следующая проблема при работе с кгасегочее - это асимметрия маршрутов. 
Запуская Егасегоц®е, вы получаете маршрут от пункта отправления до пункта 
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назначения, но нет гарантии, что датаграмма, отправленная из пункта назначения, 
будет следовать тем же маршрутом. Хотя кажется естественным предположение 
о том, что почти все маршруты одинаковы, в действительности, как показано в ра- 
боте [Рахзоп 1997], 49% изученных маршрутов демонстрируют асимметрию хотя 
бы в одном промежуточном узле. 


Примечание С помощью опции -5, которая устанавливает режим свободной 
маршрутизации, заданной источником (1о005е 5оитсе тоийпЕ) от 
пункта назначения в пункт отправления, теоретически можно 
получить оба маршрута. Но, как отмечает Джекобсон в ком- 
ментариях к исходному тексту Егасегоцке, количество мар- 
шрутизаторов, которые некорректно выполняют маршрутиза- 
цию, заданную источником, настолько велико, что этот метод на 
практике не работает. В главе 8 книги [5{е0еп$ 1994 ] объясняется 
суть метода и приводится пример его успешного применения. 


В другой работе Паксон отмечает, что асимметричные маршруты возникают 
также из-за эффекта «горячей картофелины» [Рахзоп 1995]. 


Примечание Этот эффект состоит в следующем. Предположим, что хост А, 
расположенный на восточном побережье Соединенных Штатов, 
отправляет датаграмму хосту В на западном побережье. 
Хост А подключен к Гиегтпе через провайдера 1, а хост В — 
через провайдера 2. Допустим, что у обоих провайдеров есть 
опорные сети, проходящие через всю страну. Поскольку полоса 
пропускания опорной сети — это дефицитный ресурс, провай- 
дер 1 пытается доставить датаграмму хосту в сети провай- 
дера 2, пользуясь его же опорной сетью. Но точно так же, когда 
хост В отвечает, провайдер 2 пытается доставить ответ на 
противоположное побережье, пользуясь опорной сетью провай- 
дера 1. Отсюда и асимметрия. 


Программа {гасеп в системе ИЛпдомуз 


До сих пор описывалась ОМХ-версия программы Егасегоцее. Очень похо- 
жее средство — Егасег® — есть и в различных версиях операционной системы 
УЛпдо\з. Программа Егасеге работает аналогично Егасегоц(е, но для опреде- 
ления маршрута используются не ОЮР-датаграммы, а эхо-запросы протокола 
СМР (как в программе р1па). В результате хост-получатель возвращает эхо-от- 
вет СМР, ане сообщение о недоступности порта. Промежуточные маршрутизато- 
ры по-прежнему возвращают сообщение «истекло время в пути». 


Примечание В последних версиях ЕгасегоиЕеесть опция -Т, имитирующая 
такое же поведение. Подобную версию можно получить на сай- 


те Др//Др.ее го тасетошелахй. 


Наверное, это изменение сделано исходя из соображения о том, что ОЮР-да- 
таграммы часто отфильтровываются маршрутизаторами, тогда как эхо-запросы 
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и эхо-ответы {СМР используемые программой р1п9д, менее подвержены этому. 
Исходная версия Егасегоцёе также применяла эхо-запросы для определения 
маршрута, но потом они были заменены ОПР-датаграммами, поскольку многие 
маршрутизаторы строго следовали предписанию КЕС 792 [Роз{е] 1981], требую- 
щему не посылать [СМР-сообщения в ответ на [СМР-сообщения []асоБзоп 1999]. 
Действующее ныне ВЕС 1122 [Вга4еп 1989] указывает, что [СМР-сообщение не 
должно посылаться в ответ на 1[СМР-сообщение об ошибке, но Егасеге по-пре- 
жнему встречает трудности в старых моделях маршрутизаторов. 

В ВЕС 1393 [Мат 1993] предложено добавить новую опцию в протокол [Р 
и отдельное {СМР-сообщение, чтобы гарантировать надежность Егасегоцёе (а за- 
одно и решить некоторые другие задачи), но, так как в маршрутизаторы и про- 
граммное обеспечение хостов пришлось бы вносить изменения, этот метод не по- 
лучил распространения. 


Резюме 


Утилита Егасегоцёе - очень полезный инструмент для диагностики сете- 
вых ошибок, изучения маршрутизации и исследования топологии сети. Тополо- 
гия [лбегпеё нередко достаточно запутанна, и это может быть причиной неожи- 
данного поведения приложений. С помощью Егасегоцее зачастую удается 
обнаружить аномалии в сети, из-за которых программа ведет себя странно. 

Программы Егасегоцее и Егасег® работают путем отправки хосту назначе- 
ния датаграммы с последовательно увеличивающимся значением в поле ТТТ. За- 
тем они отслеживают приходящие от промежуточных маршрутизаторов 1СМР- 
сообщения «истекло время в пути». Разница в том, что Егасегоцее посылает 
ООР-датаграммы, а Егасег+ - эхо-запросы (СМР. 


Совет 36. Используйте программу ср 


Часто необходимо иметь утилиту, которая может посылать произвольный объем 
данных другой (или той же самой) машине по протоколу ТСР или ОПР и соби- 
рать статистическую информацию о полученных результатах. В этой книге уже на- 
писано несколько программ такого рода. В этом разделе вы познакомитесь с го- 
товым инструментом, обладающим той же функциональностью. Подобное сред- 
ство можно использовать для тестирования собственного приложения или для по- 
лучения информации о производительности конкретного стека ТСР/[Р или сети. 
Такая информация может оказаться бесценной на этапе создания прототипа. 

Этот инструмент - программа ЕЕ ср, бесплатно распространяемая Лабораторией 
баллистических исследований армии США (ВЕТ. - Ваз9сз Везеагсв ГаБогабогу). Ее 
авторы Майк Муусс (автор программы р1па) и Терри Слэттери. Эта утилита доступна 
на множестве сайтов в Пцегпее. В книге будет использована версия, которую Джон 
Лин модифицировал с целью включения дополнительной статистики; ее можно 
получить по анонимному ЕТР с сайта =\еп.сз. риг4ие.еди из каталога /раБ/Йл. Версия 
без модификаций Лина находится, например, на сайте Ёр.321.сощ в каталоге $#1/ 
гс/&ср, в состав ее дистрибутива входит также страница руководства. 

У программы ЕЕср есть несколько опций, позволяющих управлять: объемом 
посылаемых данных, длиной отдельных операций записи и считывания, размерами 
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буферов приема и передачи сокета, включением или отключением алгоритма Ней- 


гла и даже 
о порядке 


выравниванием буферов в памяти. На рис. 4.11 приведена информация 
использования (ср. Дается перевод на русский язык, хотя оригиналь- 


ная программа, естественно, выводит справку по-английски. 


Порядок вызова: ЕЁср -® [-опции] хост [ < 1 |] 


Часто 
-1 


-В 
-Р 


Опции, 
п 


сЕср -г [-опции > очЕ] 
используемые опции: 
## длина в байтах буферов, в которые происходит считывание 
из сети и запись в сеть (по умолчанию 8192) 
использовать ПОР, а не ТСР 
## номер порта, в который надо посылать данные или 
прослушивать (по умолчанию 5001) 
-Е: отправить данные в сеть 
-х: считать (и отбросить) все данные из сети 
выравнивать начало каждого буфера на эту границу 
(по умолчанию 16384) 
считать, что буфер начинается с этого смещения 
относительно границы (по умолчанию 0) 
печатать более подробную статистику 
установить опцию сокета $0_РБЕВОС 
## установить размер буфера сокета (если поддерживает 
операционная система) 
Х формат для вычисления скорости обмена: К,К = кило (бит, байт); 
ш,М = мега; д3,С = гига 
употребляемые вместе с -Е: 
## число буферов, записываемых в сеть (по умолчанию 2048) 


-Р не буферизовать запись по протоколу ТСР (установить 


Опции, 
-В 


т 


опцию сокета ТСР_МОБЕГАУ) 
употребляемые вместе с -г:; 
для -в, выводить только полные блоки в соответствии 
с опцией -1 (для ТАБ) 
"Сочср": обращаться к каждому прочитанному байту 


Рис. 4.11. Порядок вызова Иср 


Поэкспериментируем с размером буфера передачи сокета. Сначала прогоним 
тест с размером буфера, выбранным по умолчанию, чтобы получить точку отсчета. 
В одном окне запустим экземпляр Е ср-потребителя: 


ЪЬзЯ: $ ЕЕер -гву 


ав другом 


— экземпляр, играющий роль источника: 


ЬзЯ: $ ЕЕср -Еву Ьва 


СЕср-Е: 


риЕ]еп=8192, пьиЕ=2048, а1191=16384/0, рогЕ=5013 Еср -> Ьза 


Есср-Е:  зоскеё 
СЕср-Е: соппесё 
Ееср-е: 16777216 рубез 1п 1.341030 геа!1 зесоп@$ 


= 12217.474628 КВ/зес (95.449021 МЬ/зес} 


ссср-е: 16777216 Бубевз 11 0.00 СРО зесопаз 


= 16384000.000000 КВ/сри зес 
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СЕеср-Е: 2048 Т/О са113, пзес/са11 = 0.67, са11з/зес = 1527.18 
СЕср-6: БаЕЁЕег ааагезз 0х8050000 
раз: $ 


Как видите, Е ср дает информацию о производительности. Для передачи 16 Мб 
потребовалось около 1,3 с. 


Примечание Аналогичная статистика печатается принимающим процессом, но 
поскольку цифры, по существу, такие же, они здесь не приводятся. 


Также был выполнен мониторинг обмена с помощью Е сраипр. Вот типичная 
строка выдачи: 


13:05:44.084576 Ъза.1061 > Ъза.5013: . 1:1449 (1448) 
аск 1м1п17376 <пор, пор, Е1мезеашр 11306 11306> (ПЕ) 


Из нее видно, что ТСР посылает сегменты по 1448 байт. 
Теперь следует установить размер буфера передачи равным 1448 байт, и по- 
вторить эксперимент. Приемник данных нужно оставить без изменения. 


ЬзЯ: $ ЕЕср -ЕвУЪЬ 1448 Ьва 
Сеср-Е: зоскКее 
Сеср-Е:  эпариаЕ 
Сеср-Е: соппесЕ 
сЕср-6: РаЕ1еп=8192, приЕЁ=2048, а119п=16384/0, рогё=5013, 
зоскриЁ$12е=1448 Еср -> Ъза 
Сеср-Е: 16777216 Бубез 110 2457.246699 геа1 зесопаз 
= 6.667625 КВ/зес (0.052091 МЬ/зес) 
ЕСср-Е: 16777216 Бубез 11 0.00 СРИ зесопаз 
= 16384000.000000 КВ/сри зес 
Сеср-Е: 2048 Т/О са115, мзес/са11 = 1228.62, са115/вес = 0.83 
СЕеср-Ее: БаЕЕег а@агезз 0х8050000 
раз: $ 


На этот раз передача заняла почти 41 мин. Следует отметить, что, хотя по ча- 
сам для передачи потребовалось больше 40 мин, время, затраченное процессором, 
по-прежнему очень мало, даже не поддается измерению. Поэтому, что бы ни про- 
изошло, это не связано с загрузкой процессора. 

Теперь посмотрим, что показывает Е срацпр. На рис. 4.12 приведены четыре 
типичные строки: 


16:03:57.168093 Ъза.1187 > Ьза.5013: Р 8193:9641 (1448) 
аск 1 зап 17376 <пор, пор, Е1тезеатр 44802 44802> (ПЕ) 
16:03:57.368034 Ъза.5013 > Ъза.1187: . аск 9641 и1п 17376 
<пор, пор,Ешпезбатр 44802 44802> (ПЕ) 
16:03:57.368071 Ъза.1187 > Ъза.5013: Р 9641:11089 (1448) 
аск 1 м1п 17376 <пор,пор,Е\щезкатр 44802 44802> (ОЕ) 
16:03:57.568038 Ъза.5013 > ъза.1187: . асКк 11089 ма 17376 
<пор, пор, 1тезеатр 44802 44802> (РЕ) 


Рис. 4.12. Типичная выдача {сраитр для запуска Иср -[5у6 1448 654 
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Обратите внимание, что время между последовательными сегментами со- 
ставляет почти 200 мс. Возникает подозрение, что тут замешано взаимодействие между 
алгоритмами Нейгла и отложенного подтверждения (совет 24). И действительно 
именно АСК задерживаются. 

Эту гипотезу можно проверить, отключив алгоритм Нейгла с помощью опции 
-р. Повторим эксперимент: 


Ьза: $ ЕЕер -ЕвУрЬ 1448 Ьва 
ЕЕср-6: РаЕ1еп=8192, пБаЕЁ=2048, а119п=16384/0, рогЕ=5013, 
зоскЬаЁ512е=1448 Еср -> Бза 
ЕЕср-Е:  воскКее 
БЕср-6:  впаБаЕ 
ЕЕср-6: соппесё 
ЕЕср-Ё: поае1ау 
ЕЕср-Е: 16777216 рубеё 1п 2457.396882 геа1 зесоп@в 
= 6.667218 КВ/зес (0.052088 МЬ/зес}) 
ЕЕср-Е: 16777216 БуЕев 1п 0.00 СРИ зесопав 
= 16384000.000000 КВ/сриа вес 
ЕЕср-6: 2048 Т/О са115, пзес/са11 = 1228.70, са115/5ес = 0.83 
ЕЕср-Е: РаЕЁЕег а@агезв 0х8050000 
раз: $ 


Как ни странно, ничего не изменилось. 


Примечание Это пример того, как опасно делать поспешные заключения. Сто- 
ило немного подумать и стало бы ясно, что алгоритм Нейгла 
тут ни при чем, так как посылаются заполненные сегменты. 
В частности, этому служит самый первый тест, - чтобы 
определить величину М$55. 


В совете 39 будут рассмотрены средства трассировки системных вызовов. То- 
гда вы вернетесь к этому примеру и обнаружите, что выполняемая ЕЕ ср операция 
записи не возвращает управление в течение примерно 1,2 с. Косвенное указание 
на это видно и из выдачи Е Е ср, где каждый вызов операции ввода/вывода занима- 
ет приблизительно 1,228 мс. Но, как говорилось в совете 15, ТСР обычно не бло- 
кирует операции записи, пока буфер передачи не окажется заполненным. Таким 
образом, становится понятно, что происходит. Когда Е ср записывает 8192 байта, 
ядро копирует первые 1448 байт в буфер сокета, после чего блокирует процесс, так 
как места в буфере больше нет. ТСР посылает все эти байты в одном сегменте, но 
послать больше не может, так как в буфере ничего не осталось. 


Примечание Из рис. 4.12 видно, что дело обстоит именно так, поскольку 
в каждом отправленном сегменте задан флаг Р5$Н, а стеки, беру- 
щие начало в системе В5О, устанавливают этот флаг только 
тогда, когда выполненная операция передачи опустошает буфер. 


Поскольку приемник данных ничего не посылает в ответ, запускается меха- 
низм отложенного подтверждения, из-за которого АСК не возвращается до исте- 
чения тайм-аута в 200 мс. 
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В первом тесте ТСР мог продолжать посылать заполненные сегменты данных, 
поскольку буфер передачи был достаточно велик (16 Кб на машине Ъ39) для со- 
хранения нескольких сегментов. Трассировка системных вызовов для этого теста 
показывает, что на операцию записи уходит около 0,3 мс. 

Этот пример наглядно демонстрирует, как важно, чтобы буфер передачи от- 
правителя был, по крайней мере, не меньше буфера приема получателя. Хотя по- 
лучатель был готов принимать данные и дальше, но в выходном буфере отправи- 
теля задержался последний посланный сегмент. Забыть про него нельзя, пока не 
придет АСК, говорящий о том, что данные дошли до получателя. Поскольку раз- 
мер одного сегмента значительно меньше, чем буфер приема (16 Кб), его получе- 
ние не приводит к обновлению окна (совет 15). Поэтому АСК задерживается на 
200 мс. Подробнее о размерах буферов рассказано в совете 32. 

Однако смысл этого примера в том, чтобы показать, как можно использовать 
Е Еср для проверки эффекта установки тех или иных параметров ТСР-соединения. 
Вы также видели, как анализ информации, полученной от ср, Е срацир и програм- 
мы трассировки системных вызовов, может объяснить работу ТСР. 

Следует упомянуть о том, как использовать программу ЕЕ ср для организации 
«сетевого конвейера» между хостами. Например, скопировать всю иерархию ка- 
талогов с хоста А на хост В. На хосте В вводите команду 


ЕЕср -ХВ | бах -хрЕ - 
на хосте А - команду 
Саг -СЕЁЕ - каталог | ЕЕср -Е А 


Можно распространить конвейер на несколько машин, если на промежуточ- 
ных запустить команду 


Сеср -г | ЕЕср -Е следующий _узел 


Резюме 


В этом разделе показано, как пользоваться программой & {ср для эксперимен- 
тирования с различными параметрами ТСР-соединения. ЕЕ ср можно применять 
также в целях тестирования собственных приложений, предоставляя для них ис- 
точник или приемник данных, работающий по протоколу ТСР либо ОПР И, нако- 
нец, вы видели, как использовать & Е ср для организации сетевого конвейера меж- 
ду двумя или более машинами. 


Совет 37. Применяйте программу [501 


В сетевом (и не только) программировании часто необходимо определить, какой 
процесс открыл файл или сокет. Особенно это важно в сетевом окружении, по- 
скольку, как было показано в совете 16, при завершении процесса, работавшего 
с сокетом, ЕПМ не будет послан, если другой процесс держит этот сокет открытым. 

Хотя ситуация, когда другой процесс держит сокет открытым, выглядит 
странно, но она часто возникает, особенно при работе в ОМХ. Происходит вот 
что: один процесс принимает соединение и запускает другой процесс, который 
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будет работать с этим соединением (кстати, именно это и делает 1пе% А - совет 17). 
Если процесс, принявший соединение, не закроет сокет после создания процесса — 
потомка, то счетчик ссылок на это сокет будет равен двум. Поэтому после того как 
потомок закроет сокет, соединение останется открытым, и Е[М не будет послан. 

Та же проблема может возникнуть и по другой причине. Предположим, что 
хост клиента, работавшего с созданным процессом, аварийно остановился, в ре- 
зультате чего потомок «завис». Такая ситуация обсуждалась в совете 10. Если про- 
цесс, принимающий соединения, завершит работу, то перезапустить его будет не- 
возможно (если, конечно, не была задана опция сокета $0_ВЕОЗЕАОВК, - совет 23), 
так как локальный порт уже привязан к созданному процессу. 

В этих и некоторых других случаях необходимо знать, какой процесс (или про- 
цессы) держит сокет открытым. Утилита пее зас (совет 38) сообщает, что неко- 
торый процесс занимает данный порт или адрес, но что это за процесс, неизвестно. 
В некоторых версиях ОМХ для ответа на этот вопрос есть программа Ёз6аЕ. Вик- 
тор Абель (У1сбог АЪе]]) написал свободно распространяемую программу 1з0Е, ра- 
ботающую почти во всех версиях ОМХ. 


ее Е Зо ыы 
Примечание Дистрибутив 650] можно получить по анонимному ЕТР с сайта 
с.ссритие.е4и из каталога рибЛооб/итх/ Бо]. 


1зоЕ — это исключительно гибкая программа; руководство по ней занимает 26 
печатных страниц. С ее помощью можно получить самую разнообразную инфор- 
мацию об открытых файлах. Как и в случае Есраипр, предоставление единого ин- 
терфейса к нескольким диалектам ОМХ - это существенное достоинство. 

Рассмотрим некоторые возможности 1зоЕ, полезные в сетевом программирова- 
нии. В руководстве приводится подробная информация и о других ее применениях. 

Предположим, что после выполнения команды пеезеаЕ -аЕ 1пе® (совет 38) 
вы обнаруживаете, что некоторый процесс прослушивает порт 6000: 


АСсЕ1уе ТпбегпеЕ соппесе1оп$ (1пс1аЯ1па зегуегз) 
Ргобо Весу-0О бепа-О Госа1 Адаагезз Еоге1ап Ааагезв (збасе) 
Е ср 0 0 *.6000 *.* .ТЗТЕМ 


Порт 6000 не относится к хорошо известным (совет 18), поэтому возникает 
вопрос: что же его прослушивает? Как уже упоминалось, в пеёзаЁ по этому по- 
воду ничего не говорится - она лишь сообщает о наличии прослушивающего про- 
цесса. Зато программа 1зоЕ не испытывает никаких затруднений: 


Ьза# 1воЕ -14 ТСР:6000 


СОММАМО РТО ОЗЕВ ЕО ТУРЕ РЕУТСЕ СТУЕ/ОЕЕ МОШЕ МАМЕ 
ХР86_Масв 253 гооЕ 0иа 1пеё0хЕ5а98840 0Е0 ТСР *:6000 —(Ъ.ТСТЕМ) 
Ьза# 


Следует отметить, что вы запускали 1 зо от имени пользователя гоо*. Это необ- 
ходимо, потому что используемая версия 1зоЁ сконфигурирована для перечисле- 
ния файлов, принадлежащих только данному пользователю, за исключением ситуа- 
ции, когда ее запускает гоо*. Это свойство направлено на обеспечение безопасности, 
но его можно отключить во время компиляции программы. Далее надо отметить, 
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что процесс был запущен пользователем гоо* с помощью команды ХЕ86_Масн. Это 
ваш Х-сервер. 

Опция -1 ТСР: 6000 означает, что 1зоЁ должна искать открытые ТСР-сокеты, 
привязанные к порту 6000. Можно было бы показать все ТСР-сокеты с помощью 
опции -1 ТСР или все ТСР-и ОШОР-сокеты - с помощью опции -1. 

Предположим, что вы еще раз запустили пеЕзеае и обнаружили, что кто-то 
открыл ЕТР-соединение с хостом \1с.сс.ригкаце. еди: 


Асе1уе Тпбсегпее соппес®1оп$ 
Ргосо Кесу-0О 5бепа-0О [оса Адагезз РЕогезлап Адагезз (зсасе} 
Еср 0 0 Ьза.1124 у1с.сс.ригаце.еаи. Еёр ЕЗТАВЬТУНЕО 


Выяснить, кто это сделал, поможет 1зоЕ: 


Ьза# 1воЕ -1 @У1с.сс.рагаче.еаа 


СОММАМО РТО ОЗЕВ ЕБ ТУРЕ РЕУТСЕ $5Т2Е/ОЕЕ МОШЕ МАМЕ 

ЕЕр 450 3сз Зи 1пеЕё 0хЕ5999Е00 0-0 ТСР Ь$а:1124-> 
У1с.сс.ригаце. еал: Еёр ЕСТАВЬТЗНЕО 

Ьза# 


Как обычно, в имени машины Ьз4 опущен домен и строка разбита на две. Из 
полученной выдачи видно, что ЕТР-соединение открыл пользователь 3сз. 

Необходимо подчеркнуть, что 130 может выдать информацию только об откры- 
тых файлах. Собственно говоря, название программы - аббревиатура 156 ореп @ез (пе- 
речислить открытые файлы). Это, в частности, означает, что с ее помощью нельзя 
получить информацию о ТСР-соединениях, находящихся в состоянии Т1ТМЕ-\УАТТ 
(совет 22), поскольку с ними не связан никакой открытый сокет или файл. 


Резюме 


Здесь показано, как можно воспользоваться утилитой 1зоЁ для получения от- 
вета на разнообразные вопросы об открытых файлах. К сожалению, нет версии 
1зоЁ для Мп о\5. 


Совет 38. Используйте программу пе{а{ 


Ядро операционной системы ведет разнообразную статистику об объектах, 
имеющих отношение к сети. Эту информацию можно получить с помощью про- 
граммы пеёзфах. Существует четыре вида запросов. 


Активные сокеты 


Во-первых, можно получить сведения об активных сокетах. Хотя пеёзеае дает 
информацию о разных типах сокетов, интерес представляют только сокеты из адрес- 
ных доменов 1пеё (АЕ_ТМЕТ) и МХ (АЕ_ГОСАЬ или АЕ_ОМТХ). Можно потребовать 
вывести все типы сокетов или выбрать один тип, указав адресное семейство с по- 
мощью опции - Е. 

По умолчанию серверы, сокеты которых привязаны к адресу ТМАРОК_АМУ, не 
выводятся, но этот режим можно отключить с помощью опции -а. Например, если 
нужны ТСР/ОПР-сокеты, то можно вызвать пеезкае так: 
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Ьз@: $ пеевеаЕе -Е 1пеё 
АсЕ1Ууе ТобегпеЕ соппесЕ1опз 


Рхосо Весу-0О бепа-0 


Еср 
Еср 
цЯр 
цар 


рза: 


Здесь показан только сервер доменных имен (патед), работающий на машине 
ьза. Если же нужно вывести все серверы, то программа запускается таким образом: 


$ 


0 


0 
0 
0 


0 


оо 


Госа1 Ааагезз 
1оса1Позе .Чома1п 


Ъза. аота1п 


]оса1ПозЕ.аота1п 


Ьза.аота1п 


Ьз4: $ пебвеае -аЕ 1пее 
АсЕ1уе Трсегпебе соппесе1опз 
Ргосо Весу-0О 5епа-0 


Еср 
Еср 
бер 
Еср 
6ср 
Еср 
Еср 
Еср 
Сер 
Еср 
Сср 
6ср 
6ср 
ср 
Еср 
Сер 
Еср 
Еср 
Сср 
Еср 
зар 
цар 
цар 
цар 
цар 
иар 
цар 
зар 
зар 
зар 
цар 
цар 
цар 
цар 
цар 


реза: 


ооо оо ооо оо оо оо оо о о о о о о оо о о о оо о о о о о осо 


0 


ооо оо о о о оо о о о о о о о о о о о о о о о о о оо со 


Госа1 Ааагезв 
*.6000 
.втЕр 
„ре1пеехк 
.Е1поам 
.Ссермах 
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ххх» 


ххх хх+&+ + + хх + х + + + хх + хх хх + + + + хх + х + + + хх + 


Боге1ап АЯдагезз 
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.ТУТЕМ 
ГТЭТЕМ 
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ЬТЭТЕМ 
ГТСТЕМ 
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ТТЗТЕМ 
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ЬТОТЕМ 
.ТЭТЕМ 
ГТЗТЕМ 
.ТЗТЕМ 
ГТ5ТЕМ 
.ТЗТЕМ 
.ТОТЕМ 
ГТЭТЕМ 
.ТЭТЕМ 
ГТЭТЕМ 
ЬТЭТЕМ 
ЬТЗТЕМ 
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Если бы вы запустили программу 130 (совет 37), то обнаружили, что боль- 
шинство этих «серверов» — в действительности 1пееЯ (совет 17), ожидающий 
прихода соединений или датаграмм в порты стандартных сервисов. Слово 
«ГТЗТЕМ» в колонке зе афе для ТСР-соединений означает, что сервер ждет запро- 
са на соединение от клиента. 

Если обратиться к серверу эхо-контроля с помощью $ е1пек: 


Ьза: $ ве1птеЕё Ьва есво 
то появится соединение в состоянии ЕЗТАВЬТЗНЕО: 


Ргобо Кесу-0 Зепа-0 Госа1 АЯагезз Еоге1дп АЯЯагезз (збабе) 


Сср 0 0 ЪзЯ.есво Ьза.1035 ЕЗТАВЬТЗНЕО 
Еср 0 0 Ьза.1035 Ьза.есво ЕЗТАВЬТ$НЕО 
Еср 0 0 *.еспо *.* ГТЗТЕМ 


Здесь опущены строки, не относящиеся к серверу эхо-контроля. Обратите 
внимание, что, поскольку вы соединились с локальной машиной, в выдаче 
пеезеае соединение присутствует дважды: один раз для клиента, а другой — для 
сервера. Заметьте также, что 1пеёа продолжает прослушивать порт в ожидании 
дальнейших соединений. 


Примечание Последнее замечание требует еще нескольких пояснений. Хотя 
ете-клиент подсоединился к порту 7 (порт эхо) и фактически 
использует его в качестве порта назначения, хост продолжает 
прослушивать этот порт. Это нормально, так как с точки зре- 
ния ТСР соединение — это четверка, состоящая из локальных [Р- 
адреса и порта и удаленных [Р-адреса и порта (совет 23). Как 
видите, 1пеёа прослушивает порт на универсальном «псевдо- 
адресе» ТМАБОЕ_АМУ, что показано звездочкой в колонке Госа! 
Аа4А@гез$, тогда как [Р-адрес для установленного соединения ра- 
вен Ьза. Если бы вы создали одно дополнительное соединение 
с помощью 4ете, то получили бы еще две строки, аналогичные 
первым двум, только порт клиента был бы отличен от 1035. 


Завершите работу клиента и снова запустите пес з{аёЕ. Вот что вы получите: 


Ргобо Весу-0О бепа-0 [Госа1 Адагевз Еоге1ап Ааагез$ (эбабе) 
Еср 0 0 Ьза.1035 Ьза.есНо ТТМЕ_МАТТ 


Как видно, клиентская сторона соединения находится в состоянии ТТМЕ-\У/АТТ 
(совет 22). В колонке зекасе могут появляться и другие состояния, подробнее 
о них рассказывается в ВЕС 793 [Розе] 1981Ъ]. 


Интерфейсы 


С помощью пе зсае можно также получить информацию об интерфейсах. Та- 
кой пример был приведен в совете 7. Основная информация выдается при нали- 
чии опции -1: 
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Ьза: $ петзтае -1 


Мате Му  Мемогк АЧЧге5$ Трк{з Теггз  Орк$ Оегг$ —С011 
е90 1500 <Е1пКк> 00.00.с0.54.53.73 40841 0 5793 0 0 
е90 1500 172.30 654 40841 0 5793 0 0 
футб» 1500 <Е1пК> 397 0 451 0 0 
Тип0» 1500 205.184.142 205.184.142.171 397 0 451 0 0 
$10* 552  <ШМпКк> 0 0 0 0 0 
100 16384 <Шпк> 353 0 353 0 0 
100 16384 127 ]1 оса] поз 353 0 353 0 0 


Отсюда видно, что В машине Ъз4 сконфигурировано четыре интерфейса. Пер- 
вый - е90- это адаптер сети Ефегпе". Он входит в частную (КЕС 1918 [Кекег, 
МозКо\/1 2 её а|. 1996]) сеть 172.30.0.0. Адрес 00.00.с0.54.73 — это первый 
в списке МАС-адресов (те1а ассез$ сопёго!] — контроль доступа к носителю) дан- 
ной сетевой карты. Через этот интерфейс прошло 40841 входных пакетов и 5793 
выходных; не было зарегистрировано ни ошибок, ни коллизий. МТО (совет 7) со- 
ставляет 1500 байт — максимальное значение для сетей Е\фегпей. 

Интерфейс Еип0 - это телефонный канал, по которому связь осуществляется 
по протоколу РРР (Рон! -о-РошЕ Ргофосо}). Он входит в сеть 205.184.142.0. МТО 
для этого интерфейса также составляет 1500 байт. 

Интерфейс з10 -— это телефонный канал, по которому связь осуществляется 
по протоколу ЭТЛР (Зена! Глпе Ицегпеё Ргобосо!), ВЕС 1055 [КошКеу 1988]. Это 
еще один, ныне устаревший протокол двухточечного соединения по телефонным 
линиям. Данный интерфейс в машине Ъза4 не используется. 

Наконец, есть еще возвратный интерфейс 100. О нем уже неоднократно говорилось. 

В сочетании с опцией -1 можно также задать опции -Ь или -4. Тогда будет 
напечатано количество байт, прошедших через интерфейс в обе стороны, или чис- 
ло отброшенных пакетов. 


Маршрутная таблица 


Кроме того, пеезеае может дать маршрутную таблицу. Назначьте опцию -п, 
чтобы получить не символические имена, а Р-адреса; так лучше видно, в какие 
сети маршрутизируются пакеты. 

Интерфейсы и соединения, выведенные на рис. 4.13, показаны и на рис. 4.14. 
Интерфейс 100 не показан, так как полностью находится внутри машины 34. 


Ьза: $ пеевфае -гп 
Вочё1па баБ1ез 


Тпбегпее: 

РезЕ1пае1оп Саб емау Е1ачз ВеЁз Озе МеЕё1Ё Ехр1ге 
ЯеЕац1 Е 163.179.44.41 965с 2 0 бип0 
127.0.0.1 127.0.0.1 ОН 1 34 1о0 
163.179.44.41 205.184.142.171 ОН 3 0 Еип0 

172.30 1101К#1 ОС 0 0 еао 
172.30.0.1 0:0:с0:54:53:73 ОН 0 132 100 


Рис. 4.13. Маршрутная таблица, выведенная программой пе а! 
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172.30.0.1 163.179.44.41 


205.184.142.171 


172.30 


(телефонное 
подключение) 


Маршрутизатор 
сервис-провайдера 


Рис. 4.14. Информация об интерфейсах и хостах, выведенная программой пе 1 


Прежде чем знакомиться с отдельными элементами этой выдачи, обсудим на- 
значение колонок. В первой колонке находится пункт назначения маршрута. Это 
может быть конкретный хост, сеть или маршрут по умолчанию. 

В колонке ЁЕ1ад5$ печатаются различные флаги, большая часть которых зави- 
сит от реализации. Следует упомянуть только следующие: 


9 9-— маршрут задействован («ОР»); 

о Н- маршрут к хосту. Если этот флаг отсутствует, то речь идет о маршруте 
к сети (или к подсети, если используется бесклассовая междоменная марш- 
рутизация СТОК - совет 2); 

О с - непрямой маршрут. Иными словами, пункт назначения не связан напря- 
мую с данным хостом, к нему следует добираться через промежуточный мар- 
шрутизатор или шлюз (С — ваве\гау). 


Легко сделать ошибку, полагая, что флаги Н и С взаимоисключающие, то есть 
маршрут может идти либо к хосту (Н), либо к промежуточному шлюзу (с). Флаг Н 
означает, что адрес в первой колонке представляет собой полный 1ТР-адрес хоста. 
Если флага Н нет, то адрес в этой колонке не содержит идентификатора хоста, ины- 
ми словами, он — адрес сети. Флаг С показывает, достижим ли адрес, проставлен- 
ный в первой колонке, непосредственно с данного хоста или необходимо пройти 
через промежуточный маршрутизатор. 


.1 192.168.2 .2 


172.20 


Рис. 4.15. Н2 выступает в роли шлюза к НЗ 


Вполне возможно, что для некоторого маршрута будут одновременно установ- 
лены флаги С и Н. Рассмотрим, например, две сети, изображенные на рис. 4.15. 
Хосты Н! и Н2 подключены к сети Еегпе с адресом 172.20. Хост НЗ соединен 
с Н2 по РРР-линии с сетевым адресом 198.168.2. 
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Маршрут к НЗ в маршрутной таблице Н1 будет выглядеть так: 


РезЕ1паЕ1оп Сасемау Р1ааз ВеЕз Озе Меё1ЁЕ Ехр1ге 
192.168.2.2 172.20.10.2 ОСН 0 0 еа0 


Флаг Н установлен потому, что 192.168.2.2 — полный адрес хоста. А флаг 
С -— так как Н1 не имеет прямого соединения с НЗ и должен идти через хост Н2 
(172.20.10.2). Обратите внимание, что на рис. 4.13 для маршрута к хосту 
163.179.44.41 нет флага С, поскольку этот хост напрямую подключен к интерфей- 
су Еап0 (205.184.142.171) в машине Ъза. 

На рис. 2.9 в маршрутной таблице Н1 не должно быть записи для НЗ. Вместо 
нее присутствует запись для подсети 190.50.2, поскольку именно в этом состоит 
смысл организации подсетей — уменьшить размеры маршрутных таблиц. Запись 
в маршрутной таблице Н1 для этой подсети выглядела бы так: 


РезЕ1па(1оп  Сабемау Е1адз ВеЕЁз Озе М№её1ЁЕ Ехр1ге 
190.50.2 190.50.1.4 ое. 0 0 еа0 


Флаг Н не установлен, так как 190.50.2 — адрес подсети, а не отдельного хоста. 
Имеется флаг С, так как НЗ не соединен напрямую с Н1. Датаграммы от НЗ к Н1 
должны проходить через маршрутизатор В1 (190.50.1.4). 

Смысл колонки Сасемау зависит от того, есть флаг С или нет. Если маршрут 
непрямой (флаг С есть), то в колонке Сасемау находится 1Р-адрес следующего 
узла (шлюза). Если же флага С нет, то в этой колонке печатается информация 
о том, как достичь напрямую подсоединенного пункта назначения. Во многих реа- 
лизациях это всегда 1Р-адрес интерфейса, к которому и подсоединен пункт назна- 
чения. В реализациях, производных от В$О, это может быть также МАС-адрес, как 
показано в последней строке на рис. 4.13. В таком случае будет установлен флаг г. 

Колонка ВеЁз содержит счетчик ссылок на маршрут, то есть количество ак- 
тивных пользователей этого маршрута. 

Колонка Озе указывает, сколько пакетов было послано по этому маршруту, а колон- 
ка Мес 1 Е содержит имя ассоциированного сетевого интерфейса, который представляет 
собой тот же объект, о котором вы получаете информацию с помощью опции -1. 

Теперь, разобравшись, что означают колонки, печатаемые командой пе зе а® 
-гп, вернемся к рис. 4.13. 

Первая строка на этом рисунке описывает маршрут по умолчанию. Именно по 
нему отсылаются датаграммы, когда в маршрутной таблице нет более точного мар- 
шрута. Например, если выполнить команду р1па пеесот4 .пеёсом. сом, то полу- 
чится такой результат: 


54: $ р1паз пеёсом4.пеесом. сом 
РТМС пебсоп4.пессом.сош (199.183.9.104): 56 Яаба Бувез 
64 Бусез Егош 199.183.9.104: 1спр_зеа=0 6&1=248 Е1ме=268.604 тз 


Поскольку нет маршрута ни до хоста 199.183.9.104, ни до сети, содержащей 
этой хост, эхо-запросы [СМР (совет 33) посылаются по маршруту по умолчанию. 
В соответствии с первой строкой выдачи пеезЕае шлюз для этого маршрута име- 
ет адрес 163.179.44.41, туда и посылается датаграмма. Строка 3 на рис. 4.13 пока- 
зывает, что есть прямой маршрут к хосту 163.179.44.41, и отсылать ему дата- 
граммы следует через интерфейс с [Р-адресом 205.184.142.171. 
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Строка 2 в выдаче - это маршрут для возвратного адреса (127.0.0.1). Посколь- 
ку это адрес хоста, установлен флаг Н. Так как хост подсоединен напрямую, то 
имеется и флаг С. А в колонке Сасемау вы видите [Р-адрес интерфейса 100. 

В строке 4 представлен маршрут к локальной сети Е\фегпее. В связи с тем, что 
на машине Ьз4 установлена операционная система, производная от ВЗО, в колон- 
ке Сасемау находится строка 1.1 пк#1. В других системах был бы просто напечатан 
[Р-адрес интерфейса, подсоединенного к локальной сети (172.30.0.1). 
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Статистика протоколов 


С помощью пес $ аё можно получить статистику протоколов. Если задать оп- 
ЦИЮ -5, ТО пе за напечатает статистические данные по протоколам 1Р, (СМР, 
[СМР ОПОР и ТСР. Если нужен какой-то один протокол, то его можно указать по- 
средством опции -р. Так, для получения статистики по протоколу ПОР следует 
ввести следующую команду: 


ЬзЯ: $ пебевеае -вр пар 
цар: 
82 адасаагатз гесе1уеа 
м1 1псошр1ебсе Веааег 
\1Ер Ба Часа 1епоЕВ ЁЕ1е1а 
и1ЕВ Баа сцескзим 
ЯгорреЯа аце со по зоскКеЕ 
ргоаасазе /пи1е1сазЕ Чабадкатз Аагорреа аце со по зоскееЕ 
ЯгорреЯ аце со Ец11 зоскКеЕе БоаЕЁЕегв 
О поЁЕ Гог БазВеа рсЬ 
81 ае11уегеа 
82 Часаагатз оцЕруцёЕ 
Ьза: $ 


оонооо 


Ниже дается перевод на русский язык, программа пес зе а использует англий- 
ский. 


цар: 
82 датаграмм получено 
с неполным заголовком 
с неправильным значением в поле длины данных 
с неправильной контрольной суммой 
отброшено из-за отсутствия сокета 
отброшено широковещательных/групповых датаграмм 
из-за отсутствия сокета 
О отброшено из-за переполнения буфера сокета 
О не для хэшированного блока управления протоколом 
81 доставлено 
82 отправлено датаграмм 


овооо 


Можно отменить печать строк с нулевыми значениями, если дважды задать оп- 
ЦИЮ -3: 


ЪЬза: $ пвеевзбае -ввер чар 
цар: 
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82 дЗасаагайз гесе1уеа 
1 агорреЯ але во по воскеё 
81 ае11уегеа 
82 Засаадхгамз оцЕрие 
Ьза: $ 


Периодический просмотр статистики ТСР оказывает очень «отрезвляющее» 
действие. На машине Ъза пеёз+а+ выводит для ТСР 45 статистических показате- 
лей. Вот строки с ненулевыми значениями, которые были получены при запуске 
пеёзбае-зэр ср: 


сер: 
446 раскеез зепё 
190 ааба расКкебз (40474 Бусез) 
213 асКк-оп1у расКебез (166 ае1ауеа) 
18 м!1паом ирЯабе раскКеёв 
32 сопЕго] раскКеёз 
405 раскеез гесе1уеа 
193 асКкз (ЁЕог 40488 Бусез) 
12 Яр11сабе аскКв 
302 расКеЕез (211353 Бубез) гесе1уеЯ 1п зеацепсе 
10 сотр1еее1у Яир11сабе расКеез (4380 Бусев) 
22 очЕе-оЕ-огаег расКкеез (16114 Бусез) 
2 м1паом ирабе раскеев 
20 соппесЕ1оп геацезез 
2 соппесе1оп ассерез 
13 соппесЕ1опв езбаЪ11зПеа (1пс]1аа1па ассерёз) 
22 соппесЕ1оп с1озеа (1пс1аЯ1тпа 0 @агорз) 
3 соппесе1опв ираабеЯя сасВеа вТтТТ оп с1ове 
3 соппесё1опв ираабеЯ сасВеа вТТ уаг1лапсе оп с1ове 
2 епЬгуоп1с соппесё1опз Ягорреа 
193 ведтепёезв ирЯабеая хЕЕ (оЁ 201 аЕЕетреёз) 
31 соггкесЕ АСК Веааег ргеЯ1се1опз 
180 соггесЕ Чаба раскее НеаЯег ргея1се1опз 


Далее дается перевод статистической информации на русский язык. 


Еср: 

446 пакетов послано 
190 пакетов данных (40474 байта) 
213 пакетов, содержащих только аск (166 отложенных) 
18 пакетов с обновлением окна 
32 контрольных пакета 

405 пакетов принято 
193 асКк (на 40488 байт) 
12 повторных аск 
302 пакета (211353 байта) получено по порядку 
10 пакетов - полных дубликатов (4380 байт} 
22 пакета не по порядку (16114 байта) 
2 пакета с обновлением окна 
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20 запросов на соединение 
2 приема соединения 
13 соединений установлено (включая принятые) 
22 соединения закрыто (включая 0 сброшенных} 
3 соединения при закрытии обновили КТТ в кэше 
3 соединения при закрытии обновили дисперсию КТТ в кэше 
2 эмбриональных соединения сброшено 
193 сегмента обновили ге (из 201 попыток) 
31 правильное предсказание заголовка АСК 
180 правильных предсказаний заголовка пакета с данными 


Эта статистика получена после перезагрузки машины Ъ3з& и последовавших за 
ней отправки и получения нескольких сообщений по электронной почте, а также 
чтения нескольких телеконференций. Если предположить, что такие события, как 
доставка пакетов не по порядку или получение дубликатов пакетов, происходят 
очень редко, то полученная информация полностью развеет эти иллюзии. Так, из 
405 полученных пакетов 10 оказались дубликатами, а 22 пришли не по порядку. 


Примечание В работе [Веппей, её а. 1999 ] показано, что приход пакетов не по 
порядку не обязательно свидетельствует о неисправности. Так- 
же объясняется, почему в будущем следует ожидать широкого 
распространения этого явления. 


Программа пе {а в ИЛпао\и5 


Выше рассмотрено, как работает программа пеезваё в системе О МХ. В УЙп- 
4о\из тоже есть аналогичная программа, принимающая в основном те же опции 
и выдающая такие же данные. Формат выдачи очень напоминает то, что вы виде- 
ли, хотя состав информации не такой полный. 


Резюме 


Здесь приведены утилита пеё за и те сведения о системе, которые можно по- 
лучить с ее помощью. пеёзфае сообщает об активных сокетах, о сконфигуриро- 
ванных сетевых интерфейсах, о маршрутной таблице и о статистике протоколов. 
Иными словами, она выдает отчеты о самых разнообразных аспектах сетевой подсис- 
темы, причем в различных форматах. 


Совет 39. Применяйте средства 
трассировки системных вызовов 


Иногда при отладке сетевых приложений нужно уметь трассировать обраще- 
ния к ядру операционной системы. Вы уже встречались с подобной ситуацией 
в совете 36 и вскоре вернетесь к этому примеру. 

В большинстве операционных систем есть разные способы трассировки сис- 
темных вызовов. В В$О это утилита кегхасе, в ЗУВА (и $0]а115) — Ехизз, ав - 
пих — зСхасе, 
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Все эти программы похожи, поэтому остановимся только на КЕгасе. Беглого 
знакомства с руководством по Егизз или зе гасе должно быть достаточно для 
применения аналогичной методики в других системах. 


Преждевременное завершение 


Первый пример - это вариация на тему первой версии программы эВаеао\тс 
(листинг 3.1), которая разработана в совете 16. Идея программ ЪаЯ9с11епе 
и зНаЕаомтс та же; читаются данные из стандартного ввода, пока не будет полу- 
чен признак конца файла. В этот момент вы вызываете эвиЕЯоит для отправки 
ЕП\-сегмента удаленному хосту, а затем продолжаете читать от него данные, пока 
не получите ЕОЁ что служит признаком прекращения передачи удаленным хос- 
том. Текст программы Ба@Яс11епЕ приведен в листинге 4.2. 


Листинг 4.2. Некорректный эхо-клиент 


Баас]1епЕ. с 
1 #пс1аае "ебср.В" 
2 116 ма1п( 106 агас, сах **атау } 


3 { 
4 ЗОСКЕТ 3; 
5 Е9_зеё геа@мазКк; 
6 Е9а_зеё а11геа@з; 
7 116 гс; 
8 106 1еп; 
9 спаг 11п[ 1024 }; 
10 спах 1о0о46[ 1024 ]; 
11 ТМТТ(); 
12 $ = Еср_с11епё( агду[ орЕ1па ], агду[ орЕ1та +1] ); 
13 РР_2ЕКО( &а1]1геа@аз$ ); 
14 ЕО _ЗЕТ( 0, &а11хеааз ); 
15 РО ЗЕТ( $, &а11геааз ); 
16 Рог (;; ) 
17 { 
18 геаапазк = а1]геа@з; 
19 гс = зе1есе( з + 1, &геадтазк, МОШЫ, МОБЬ, Ш, ); 
20 ЧЕ Ста <=0) 
21 еггог( 1, еггпо, "зе]ес® вернула (%а)", гс ); 
22 1Е ( РО_Т55ЕТ( $, &геа@дтазк ) ) 
23 { 
24 гс = гесу( $, 11а, $12еоЕ( 111 ) - 1,0); 
25 Ес аа 0:3 
26 еггог( 1, егхпо, "ошибка вызова гесу" ); 
27 1Е (гс == 0 ) 
28 ехгог( 1, 0, "сервер отсоединился\п" }; 
29 110[ гс } = '\0:; 
30 1Е ( Ераёз( 111, эзЕаоде ) ) 
31 еггог( 1, еггпо, "ошибка вызова Ёраез" ); 
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33 1Е ( РО Т5ЗЕТ( 0, &геаапазКк } ) 

34 { 

35 1Е ( Едеез( 1очЕ, злхеоЁ( 1046 ), эзба ) == МШ ) 
36 { 

37 1Е ( эзрабаот (в, 1 ) ) 

38 еггог( 1, еггпо, "ошибка вызова эзпабаотт" }; 
39 } 

40 е1 зе 

41 { 

42 1еп = эзбу1еп( 1ойё }; 

43 тс = зеп@а( 5, 1046, 1еп, 0); 

44 1Е (тс < 0) 

45 еггог( 1, еггпо, "ошибка вызова зепа" ); 

46 } 

47 } 

48 } 

49 } 


Баас]1епё.с 


22-32 Если зе1ес& показывает, что произошло событие чтения на соедине- 
нии, пытаемся читать данные. Если получен признак конца файла, то 
удаленный хост прекратил передачу, поэтому завершаем работу. В про- 
тивном случае выводим только что прочитанные данные на зе доц. 


33-47 


Если зе1ес®е показывает, что произошло событие чтения на стандарт- 


ном вводе, вызываем Едеез для чтения данных. Если Едеёз возвращает 
МОЪТ, что является признаком ошибки или конца файла, то вызываем 
Нас аомт, чтобы сообщить удаленному хосту о прекращении передачи. 
В противном случае посылаем только что прочитанные данные. 


А теперь посмотрим, что произойдет при запуске программы ЪаЯс11еп.. В ка- 
честве сервера в этом эксперименте будет использоваться программа Е среспо (ли- 
стинг 3.2). Следует напомнить (совет 16), что вы можете задать число секунд, на 
которое Е среспо должна задержать отправку ответа на запрос. Установите задерж- 
ку в 30 с. Запустив клиент, напечатайте ве11о и сразу нажмите СЫ1+), таким 
образом посылается Едеез признак конца файла. 


ЬзЯ: $ Есресво 9000 30 
спустя 30 с 
Есресбо: ошибка вызова гесу: 
СоппесЕ1оп гезеЕ Бу реег (54) 
Ьза: $ 


рза: $ БЬаас13епе Ъва 9000 
Ъе11о 


^р 
Баас11епё: сервер отсоединился 
Ьза: $ 


Как видите, раЯс1 1еп{ завершает сеанс сразу же с сообщением о том, что сер- 
вер отсоединился. Но ссресво продолжает работать и «спит», пока не истечет 30 с 
тайм-аута. После этого программа получает от своего партнера ошибку Соппес- 


Е 1оп гезеф Ъу реег. 


Это удивительно. Ожидалось, что ссресво через 30 с пошлет эхо-ответ, а за- 
тем завершит сеанс, прочтя признак конца файла. Вместо этого БаЯс11епе завер- 
шает работу немедленно, а ЕсресНо получает ошибку чтения. 
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Правильнее начать исследование проблемы с использования Еср@итр (совет 
34), чтобы понять, что же на самом деле посылают и принимают обе программы. 
Выдача Е срЯаитр приведена на рис. 4.16. Здесь опущены строки, относящиеся 
к фазе установления соединения, и разбиты длинные строки. 


1 18:39:48.535212 рза.2027 > Ьза.9000: 
Р 1:7(6) асКк 1 м1 17376 <пор, пор, 1щезбапр 742414 742400> (0Е} 
2 18:39:48.546773 6за.9000 > Ь$а.2027: 
аск 7 м1п 17376 <пор, пор, 1тезбатр 742414 742414> (ПЕ) 
3 18:39:49.413285 рза.2027 > Ь$9.9000: 
Е 7:7(0) аск 1 мт 17376 <пор, пор, Е1щезбатр 742415 742414> (0Е) 
4 18:39:49.413311 3а.9000 > Ьза.2027: 
аск 8 м1п 17376 <пор, пор. Е1тезбатр 742415 742415> (ОЕ) 
5 18:40:18.537119 рза.9000 > Ьза.2027: 
Р 1:7(6) асКкК 8 м1п 17376 <пор, пор, б1щезеапр 742474 742415> (ПК) 
6 18:40:18.537180 5за.2027 > Ьза.9000: 
В 2059690956:2059690956 (0) м1п 0 


Рис. 4. 16. Текст, выведенный {сраитр для программы Баас!ет 


Все выглядит нормально, кроме последней строки. Программа ра@Яс11епе посы- 
лает Е сресНо строку Не11о (строка 1), а спустя секунду появляется сегмент ЕТХ, по- 
сланный в результате зпиедотт (строка 3). Программа Е среспо в обоих случаях от- 
вечает сегментом АСК (строки 2 и 4). Через 30 с послетого, как раЯс11еп отправила 
Ве11о, Есреспо отсылает эту строку назад (строка 5), но другая сторона вместо того, 
чтобы послать АСК, возвращает В$Т (строка 6), что и приводит к печати сообщения 
СоппесЕ1оп гезе Бу реек. КТ был послан, поскольку программа раЯс11еп уже 
завершила сеанс. 

Но все же видно, что ЕсресНо ничего не сделала для преждевременного завер- 
шения работы клиента, так что вся вина целиком лежит на раЯс11епе. Посмот- 
рим, что же происходит внутри ЪаЯс11еп%, поможет в этом трассировка систем- 
НЫХ ВЫЗОВОВ. 

Повторим эксперимент, только на этот раз следует запустить программу так: 


Ьза: $ Кегасе Ьа@с11епе Ъва 9000 


При этом раЯс11епе работает, как и раньше, но дополнительно вы получаете 
трассу выполняемых системных вызовов. По умолчанию трасса записывается в файл 
КЕгасе . оцЕ. Для печати содержимого этого файла надо воспользоваться программой 
Каир. Результаты показаны на рис. 4.17, в котором опущено несколько начальных 
вызовов, относящихся к запуску приложения и установлению соединения. 

Первые два поля в каждой строке - это идентификатор процесса и имя испол- 
няемой программы. В строке 1 вы видите вызов геа@ с дескриптором Ё4, равным 
(зЕ 411). В строке 2 читается шесть байт (СТО - сокращение от &епега] [/О - об- 
щий ввод/вывод), содержащих пе11о\п. В строке 3 показано, что вызов геа@ 
вернул 6 - число прочитанных байтов. Аналогично из строк 4-6 видно, что 
программа Ъа@с1 еп писала в дескриптор 3, который соответствует сокету, соединен- 
ному с ЕсресНо. Далее, в строках 7 и 8 показан вызов зе1ес®, вернувший единицу. 
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1 4692 Баас11етЕ САШЬ геаа(0,0х804е000,0х10000) 
2 4692 РаЯас11ере сто Еа О геаа 6 БуЕев 
"Ре11о 
3 4692 Баас11ерЕ ВЕТ геаа 6 
4 4692 Баас11ерЕ САФШЬ зепабо (0х3 ,ОхеЕБЕсеб8,0х6,0,0,0) 
5 4692 Баас11ерЕ сто Еа 3 мигобе 6 БуЕез 
“Не11о 
6 4692 Баас11епЕ ВЕТ зепабо 6 
7 4692 раас11епЕ САШЬ зе1ес® (0х4 ,ОхеЕЬЕа6ЁО,0,0,0) 
8 4692 Баас11епЕ ВЕТ зе1есЕ 1 
9 4692 Баас11епЕ САШЬ геаа(0,0х804е000,0х10000) 
10 4692 раас11ерЕ СТО Еа 0 геаа 0 Бусев 
11 4692 Баас11епЕ ВЕТ геаа 0 
12 4692 Баас11ерЕ САБЬ зрабаомт (0х3 ,0х1) 
13 4692 Баас11епЕ ВЕТ эзрабаомр 0 
14 4692 Баас11евЕ САШ, зе1есЕ (0х4 ,О0хеЕБЕа6ЕО,0,0,0) 
15 4692 Баас11епЕ ВЕТ зе1есЕ 1 
16 4692 Баас11епе САШ, зпабаомт (0х3 ,0х1) 
17 4692 Баас11ерЕ ВЕТ зпибаойр 0 
18 4692 раас11епе САБ зе1ес® (0х4 ,0хеЕЬЕа6Ео,0,0,0) 
19 4692 Баас11епЕ ВЕТ зе1есЕ 2 
20 4692 раас11епЕ САШЬ гесуЕгом (0х3 ,0хеЕЪЕа268 , ОхЗЕЕ, 0,0,0) 
21 4692 Раас11ерЕ сто Еа 3 геаа 0 Бусез 
22 4692 Баас11епе ВЕТ гесуЕгом 0 
23 4692 Баас11епЕ САШ, и\тг1Ее (0х2, ОхеЕЬЕс6Е4,0хь) 
24 4692 раас11епЕ СТО Еа 2 игобе 11 БуЕевз 
"Баас11епе: " 
25 4692 Баас11епЕ ВЕТ мг1ее 11/0хь 
26 4692 Ба@ас11епе САШ, мг1Се (0х2, ОхеЕБЕс700,0х14) 
27 4692 Ъаас11епЕ сто а 2 мгобе 20 БуЕез 
"зегуег А1зсоппесвеа 
28 4692 Баас11епЕ ВЕТ мг1бе 20/0х14 
29 4692 Баас11ерЕ САШ, ех1* (0х1) 


Рис. 4.17. Результаты прогона Баасйеп!Е под управлением К!гасе 


Это означает, что произошло одно событие. В строках 9-11 фаЯс11епе прочитала 
ЕОЕ из зЕа1п и вызвала зпаЕоит (строки 12 и 13). 

До сих пор все шло нормально, но вот в строках 14-17 вас поджидает сюрп- 
риз: зе1ес& возвращает одиночное событие, и снова вызывается зпиёЯоит. Озна- 
комившись с листингом 4.2, вы видите, что такое возможно только при условии, 
если дескриптор 0 снова готов для чтения. Но геаа не вызывается, как можно 
было бы ожидать, ибо Едеез в момент нажатия Си1+0 отметила, что поток нахо- 
дится в конце файла, поэтому она возвращается, не выполняя чтения. 
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Примечание Вы можете убедиться в этом, познакомившись с эталонной реали- 
зацией ЕдеЕз (на основе ЕдеЕс) в книге [Кепиейап апа Кисше 1988] 


В строках 18 и 19 зе1есЕ возвращает информацию о событиях на обоих де- 
скрипторах Е А1п и сокете. В строках 20-22 видно, что хесуЁгом возвращает нуль 
(конец файла), а оставшаяся часть трассы показывает, как Бадс11еп выводит со- 
общение об ошибке и завершает сеанс. 

Теперь ясно, что произошло: зе1ес® показывает, что стандартный ввод готов 
для чтения в строке 15, поскольку вы забыли вызвать РО_СГВ для 691 п после пер- 
вого обращения к зна доут. А следующий (уже второй) вызов подом вынуж- 
дает ТСР закрыть соединение. 


Примечание Вэтом можно убедиться, посмотрев код на странице 1014 кни- 
ги [пе апа Зеиепз 1995 |, где показано, что в результате об- 
ращения к эриЕаойп вызывается функция Еср_изгс1о5е4. 
Если зВиЁ дот уже вызывался раньше, то соединение находит- 
ся в состоянии НМ№-УМА[Т-2 и Еср_изгс1овеа вызывает функ- 
цию 5015915соппесЕеа (строка 444 на странице 1021). Этот 
вызов окончательно закрывает сокет и заставляет зе1есЕ вер- 
нуть событие чтения. А в результате будет прочитан ЕОЕ 


Поскольку соединение закрыто, гесуЁхом возвращает нуль, то есть признак кон- 
ца файла, и Бас] 1еп Е выводит сообщение «сервер отсоединился» и завершает сеанс. 

Ключ к пониманию событий в этом примере дал второй вызов зна оит. Лег- 
ко обнаружилось отсутствующее обращение к ЕГ_СТЪВ. 


Низкая производительность Нср 


Следующая ситуация - это продолжение примера из совета 36. Помните, что 
при размере буфера равном М$$ соединения, время передачи 16 Мб возросло с 1,3 
с до почти 41 мин. 

На рис. 4.18 приведена репрезентативная выборка из результатов прогона КЕгасе 
для этого примера. 


12512 ЕЕср 0.000023 САШ, иг1ее (0х3,0х8050000, 0х2000) 
12512 ЕЕср 1.199605 СТО Еа 3 мгобе 8192 БуЕез 

12512 ЕЕср 0.000442 ВЕТ иг1се 8192/0х2000 

тата: Еве .000022 САЦ иг1е(0х3,0х8050000, 0х2000) 
12512 ЕЕср 1.199574 СТО Еа 3 игобе 8192 Бусез 


|<) 


12512 ЕЕср 0.000442 ВЕТ иг1се 8192/0х2000 
12512 ЕЁср 0.000023 САМ, \итг1%е(0х3,0х8050000, 0х2000) 
12512 ЕЕер 1.199514 вто Еа 3 игоЕе 8192 Бусевз 


12512 ЕЕср 0.000432 ВЕТ ит1ее 8192/0х2000 


Рис. 4.18. Выборка из результатов проверки Нср -15уЬ 1448 Ь54 под управлением 
Кгасе 
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Вызвана Каир со следующими опциями: 
Кацир -В -м -1 


для печати интервалов времени между вызовами и запрета вывода 8 Кб данных, 
ассоциированных с каждым системным вызовом. 

Время каждой операции записи колеблется около значения 1,2 с. На рис. 4.19 
для сравнения приведены результаты эталонного теста. На этот раз разброс значе- 
ний несколько больше, но среднее время записи составляет менее 0,5 мс. 

Большее время в записях типа СТО на рис. 4.18 по сравнению с временем на 
рис. 4.19 наводит на мысль, что операции записи блокировались в ядре (совет 36). Тог- 
да становится понятна истинная причина столь резкого увеличения времени передачи. 


12601 ЕЕср 0.000033 САШ, мг1&е(0х3,0х8050000, 0х2000) 
12601 ЕЁЕср 0.000279 СТО Еа 3 мгове 8192 БуЕез 

12601 ЕЕср 0.000360 ВЕТ иг1се 8192/0х2000 

12601 ЕЕср .000033 САШ. иг1е(0х3,0х8050000, 0х2000) 
12601 ЕЕср 0.000527 СТО Еа 3 мкоке 8192 Бусез 


ин 


<> 


12601 ЕЕср 0.000499 ВЕТ мг1се 8192/0х2000 
12601 ЕЕср 0.000032 САД, мхк1бе(0х3,0х8050000, 0х2000) 
12601 СЕср 0.000282 СТО Еа 3 мгобе 8192 Бубез 


12601 сЕср 0.000403 ВЕТ уг1бе 8192/0х2000 


Рис. 4.19. Репрезентативная выборка из результатов проверки Иср -5у 654 
под управлением К!гасе 


Резюме 


Здесь описано два способа применения утилиты трассировки системных вы- 
зовов. В первом примере ошибку удалось обнаружить путем анализа системных 
вызовов, выполненных приложением. Во втором примере надо было отслеживать 
не очередность системных вызовов, а время выполнения некоторых из них. 

Ранее уже говорилось о том, что для выяснения причин аномального поведения 
программы часто бывает необходимо сопоставить результаты, полученные от раз- 
личных утилит. Программы трассировки системных вызовов, такие как КЕгасе, 
сгизз и э6гасе, — этоеще одно средство анализа в арсенале сетевого программиста. 


Совет 40. Создание и применение программы 
для анализа !СМР-сообщений 


Иногда необходимо знать, какие сообщения приходят в протоколе [СМР Ко- 
нечно, для их перехвата всегда можно воспользоваться программой Есраипр или 
другим сетевым анализатором, но иногда простой инструмент оказывается более 
удобным, Применение Есраипр влечет за собой некоторое снижение производи- 
тельности, а также угрозу безопасности, хотя прослушивание {СМР-сообщений 
совершенно безобидно и ненакладно. 
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Во-первых, для работы такового сетевого анализатора, как Е срацир, нужно пе- 
ревести сетевой интерфейс в режим пропускания. Это увеличивает нагрузку на 
центральный процессор, так как прерывание будет возникать при проходе через 
интерфейс каждого пакета Е\фегпее, даже если он адресован не той машине, на 
которой работает анализатор. 

Во-вторых, во многих организациях применение сетевых анализаторов огра- 
ничено или вообще запрещено из-за потенциальной опасности перехвата инфор- 
мации и кражи паролей. Поэтому чтение [СМР-сообщений там более приемлемо. 

В данном разделе разработан инструмент, который позволяет отслеживать [СМР- 
сообщения и не имеет недостатков, присущих сетевому анализатору общего назначе- 
ния. Это позволит изучить простые сокеты, с которыми вы пока не сталкивались. 

В совете 33 упоминалось, что [СМР-сообщения транспортируются в составе [Р- 
датаграмм. Обычно содержимое [СМР-сообщения зависит от его типа, но интерес 
представляют только поля 1спр_буре и 1спр_соде, показанные на рис. 4.20. Допол- 
нительные поля будут рассмотрены в связи с сообщениями о недоступности ресурса. 


0 78 15 16 31 


Тип Код 


Содержимое, зависящее 
оттипа и кода 


Рис. 4.20. Общий формат /СМР-сообщения 


Часто возникают недоразумения при ответе на вопрос, что такое простые со- 
кеты и для чего они нужны. Простые сокеты нельзя использовать для перехвата 
ТСР-сегментов или ООР-датаграмм, поскольку они таким сокетам не передают- 
ся. Не годятся они и для получения всех [СМР-сообщений. Например, в системах, 
производных от В$О, эхо-запросы [СМР запросы о временном штампе и запросы 
маски адреса полностью обрабатываются ядром и не передаются простым сокетам. 
В общем случае простой сокет получает все [Р-датаграммы, в заголовках которых 
указан неизвестный ядру протокол, большинство 1СМР-сообщений и все без ис- 
ключения 1СМР-сообщения. 

Важно также отметить, что в простой сокет поступает вся [Р-датаграмма це- 
ликом, включая заголовок. Ваша программа должна будет пропускать [Р-заго- 
ловок. 


Чтение 1СМР-сообщений 
Начнем с включаемых в программу файлов и функции па1п (листинг 4.3). 


Листинг 4.3. Функция тат программы стр 


1стр.с 


1 #1пс1аае <зуз/курез.Н> 
2 #1пс1аае <пес1пее/1п_зузем.В> 


Анализ МР - сообщений 


#10с1а4е «<пеб1тее/1п-. И> 
#1пс1а4е <«пеб1тее/1р.п> 
#10с1а4е <пеб1пек/1р_1стр.В> 


#1пс1и4е "ебср.В" 


3 
4 
5 
6 #1пс1аае «<пее1пек/аар.В> 
7 
8 


106 ма1п( 116 агас, свагк **агау ) 


28 
вы 


СОСКЕТ 5; 

зЕгисе ргобоепе *рр; 
106 гс; 

спаг 1сир@аа[ 1024 1; 


ТМТТ(); 
рр = чебргоборупаме( "1смр" ); 
1Е (Бр == Ш ) 
еггог( 1, еггпо, "ошибка вызова десргобоБупаме" 
$ = воскее( АЕ _ТМЕТ, $О0ОСК_КВАМ, рр->р_ргобо }; 
1Е ( 1!1°уа11азосКк( в ) ) 
еггог( 1, еггпо, "ошибка вызова зосКес" }; 


ен ва В 
{ 
гс = гесуЁгом( $, 1стр@ад, $12еоЁ( 1спраа ), 0, 
МОЬЬ, МОБЬ ); 
1Е (ус < 0) 
еггог( 1, еггпо, "ошибка вызова гесуУЁгом" }; 
рх1пе_а9( 1спираа, гс }; 


Открытие простого сокета 
15-20 Поскольку использован простой сокет, надо указать нужный прото-кол. 
Вызов функции десргоборупаме возвращает структуру, содержа- 
щую номер протокола [СМР Обратите внимание, что в качестве типа 
указана константа 5ОСК_ВАМ, а не $0ОСК_5ТВЕАМ или 50СК_ОСВАМ, как 


раньше. 


Цикл обработки событий 


21-28 Читаем каждую [1Р-датаграмму, используя гесуЁгот, как и в случае 
ООР-датаграмм. Для печати поступающих [СМР-сообщений вызыва- 


ем функцию рг1пё_ 99а. 


Печать 1СМР-сообщений 


Далее рассмотрим форматирование и печать 1{СМР-сообщений. Это делает 
функция рк1пЕ_да, показанная в листинге 4.4. Передаваемый этой функции бу- 
фер имеет структуру, показанную на рис. 4.21. 

Из рис. 4.21 видно, что буфер содержит ГР-заголовок, за которым идет соб- 
ственно [СМР-сообщение. 


ТГ 1 289. 


ру 


зем. Е 
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0 34 78 15 16 31 


Длина 
р заголовка Тип сервиса ее о 
(12-7 | (1р_в1) 
Смещение 
Время Контрольная сумма 


Адрес источника 
(1р_екс) 


Адрес назначения 
(1р_@36} 


Опции [Р (если есть) 


Тип Код Контрольная сумма 
({1спр_буре) {1спр_соае) СКМР-сообщения 


Дополнительные !{СМР-данные 


м Р-заголовок а 


ОЕ = флаг «не фрагментировать» 
МЕ= флаг «есть еще фрагменты» 


Рис. 4.21. 1[СМР-сообщение, передаваемое функции рипЁ 49 


Листинг 4.4. Функция рипЕ 49 


1стр.с 
$баЕ1с \о0о1а рг1пЕ_@ач( сВаг *Яаа, 116 1еп ) 
{ 


1 

2 

3 зЕгасЕ 1р *15; 

4 зЕгисе 1стр *1спр; 
5 вЕгисе Позбепё *Вр; 
6 СсПахк *Ппапе; 

7 

8 


11 №1; 
5саё1с спак *хед1гесЕ_соае[] = 
9 { 
10 "сеть", "хост", 
11 "тип сервиса и сеть", "тип сервиса и хост" 
12 | 
13 збаЕ1с сраг *Е1мехсееа_со@ае[] = 
14 { 
15 "транзите", "сборке" 
16 }; 
17 $Саё1с сНаг *рагап_соае[] = 


18 { 
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ТЯ 
20 


21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
ЭТ 
32 
3-2 
34 
35 
36 
37 
38 
3.9 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 } 


"Плохой ТР-заголовок", "Нет обязательной опции" 


1р = ( зЕкисЕ 1р * )9“; 
1Е ( 1р->ру 1=4) 


еггог( 0, 0, "ТР-датаграмма не версии 4\п" }; 
гебагп; 


Ь1 = 1р->1р_ №1 << 2; /* Длина ТР-заголовка в байтах. */ 
1Е ( ]1еп < Ъ1 + ТСМР_МТМЬЕМ )} 


еггог( 0, 0, "“"зрогЕ ЯЧабадгат (%а Бубез) Егом %$\п", 
1еп, 1пеб_пбоа( 1р->1р_евгс ) ); 


гебагп; 
} 
Юр = деерозЕБуааак( ( срагк * )&1р->1р_вгс, 4, АЕ_ТМЕТ ); 
ЗЕ ( Вр == МЫ, ) 
Браме = ""; 
е1зе 
Юпаме = Юр->Ю_папе; 
1стр = ( зЕкасЕ 1стр * )( 93 +11 }); /* ТСМР-пакет. */ 


резпЕЁ( "ТСМР %5 (%А) от %3 (%$)\п", 
деЕ_вуре( 1спр->1стр_буре ), 
1стр->1спр_буре, Бпаме, 1пеб_пбоа( 1р->1р_эвгс ) ); 
1ЁЕ ( 1спр->1сшр_буре == ТСМР_ОМВЕАСН ) 
рг1пЕ_ипгеасраЬ1е( 1спр ); 


е1зе 1Ё ( 1спр->1стр_буре == ТСМР_ВЕШТВЕСТ ) 
рк1пЕЁ( "\ЕПеренаправление на %5\п", 1спр->1спр_со4е <= 3? 
геЯ1гесе_соае[ 1спр->1спр_со@ае |] : "Некорректный код" }; 
е1зе 1Ё ( 1спр->1спр_буре == ТСМР_ТТМХСЕЕР ) 
ру1пЕЁЕ( "\ЕТТЬ == 0 при %$\п", 1спр->1стр_со@ае <= 1? 
Е 1пехсее4_соае[ 1спр->1спр_соае ] : "Некорректный код" ); 
е15е 1Ё ( 1спр->1стр_вуре == ТСМР_РАВАМРВОВ ) 
рЕ1пЕЕ( "\6%5\п", 1стр->1стр_со@е <= 1? 
рагам_соае[ 1сшр->1спр_соае ] : "Некорректный код" }; 


1спр.с 


Получение указателя на !Р-заголовок и проверка корректности пакета 


21 


22-26 


27-33 


Записываем в переменную 1р указатель на только что прочитанную 
датаграмму, приведенный к типу зЕгасЕ 1р *. 

Поле 1р_у - это версия протокола ТР. Если протокол не совпадает 
с [Ру4, то печатаем сообщение об ошибке и выходим. 

Поле 1р_в1 содержит длину заголовка в 32-байтных словах. Умножа- 
ем его на 4, чтобы получить длину в байтах, и сохраняем результат 
в переменной 11. Затем проверяем, что длина 1СМР-сообщения не 
меньше минимально допустимой величины. 
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Получение имени хоста отправителя 
34-38 Используем адрес источника в {СМР-сообщении, чтобы найти имя хо- 


ста отправителя. Если чеквозеруаааг вернет МОТ, то записываем 
в Бпапе пустую строку, в обратном случае - имя хоста. 


Пропуск 1Р-заголовка и печать отправителя и типа 
39-42 Устанавливаем указатель 1 стр на первый байт, следующий за 1Р-заго- 


ловком. Этот указатель используется далее для получения типа {СМР- 
сообщения (1стр_6уре) и печати типа, адреса и имени хоста отпра- 
вителя. Для получения АЗСП-представления типа [СМР вызываем 
функцию дес _суре, текст которой приведен в листинге 4.5. 


Печать информации, соответствующей типу 
43-44 Если это одно из [{СМР-сообщений о недоступности, то вызываем функ- 


45-47 


48-50 


51-53 


цию рЕ1пёЕ_ппгеасва Те (листинг 4.6) для печати дополнительной 
информации. 

Если это сообщение о перенаправлении, то получаем тип перенаправ- 
ления из поля 1спр_соае и печатаем его. 

Если это сообщение об истечении времени существования, из поля 
1 спр_собе узнаем, произошло ли это во время транзита или сборки 
датаграммы, и печатаем результат. 

Если это сообщение о некорректном параметре, из поля 1спр_соае 
определяем, в чем ошибка, и печатаем результат. 


Функция деЕ_вуре очевидна. Вы проверяете допустимость кода типа и воз- 
вращаете указатель на соответствующую строку (листинг 4.5). 


Листинг 4.5. Функция де! уре 


1стр.с 


1з6ае1с сраг *деб буре( цпз1апеа 1спирбуре ) 


2{ 
3 


{ 


збаЁ1с сраг *вуре[] = 


"Эхо-ответ", и* о */ 
"ТСМР Тип 1", /* 1 */ 
"ТСМР Тиц 2", их а */ 
"Пункт назначения недоступен", 1.3 * 
"Источник приостановлен", /* 4 */ 
"Перенаправление", мы 
"ТСМР Тип 6", о Вы 
"ТСМР Тип 7", 7 
"Эхо-запрос", /* 8 */ 
"Отклик маршрутизатора", о 
"Поиск маршрутизаторов", у 
"Истекло время существования", /* 11 */ 
"Неверный параметр", О 
“Запрос временного штампа", уж 13: */ 
"Ответ на запрос временного штампа", /* 14 */ 
"Запрос информации", /* 15 */ 


Анализ 1СМР - сообщений ИТГ тТ | |293 


21 "Ответ на запрос информации", у* 16. * 
22 "Запрос маски адреса", Де 17 
23 "Ответ на запрос маски адреса" /* 18 */ 
24 }; 


25 1Е ( 1спрЕуре < ( з12еоЁ( ®вуре ) / з1хеоЁ( буре [Г 0] } ) ) 
26 гебигр буре[ 1сшреуре 1; 
27 гебаги "НЕИЗВЕСТНЫЙ ТИП"; 
28 } 
1сптр.с 


Последняя функция - это рг1п®_мпгеасва 1е. {СМР-сообщения о недоступно- 
сти содержат ГР-заголовок и первые восемь байт той ГР-датаграммы, из-за которой 
было сгенерировано сообщение о недоступности. Это позволяет узнать адреса и но- 
мера портов отправителя и предполагаемого получателя недоставленного сообщения. 

Структура ГР-датаграммы, прочитанной из простого сокета в составе 1СМР- 
сообщения о недоступности, показана на рис. 4.22. Та часть, которую уже обрабо- 
тала функция рг1пЕ_99, заштрихована, она не передается в рг1п_ипгеасваЪ]1е. 
Приведены также входной параметр функции рг1пе_ипгеасраЪ1е - 1спр и ло- 


кальные переменные 1р и чар. 
КМР- ЦБР- 
8 20 0-40 8 
1сптр Зр цар 


20 байт 


Рис. 4.22. 1[СМР-сообщение о недоступности 


Функция рг1п 6 _ипгеасва 1е извлекает информацию из заголовка и первых 
восьми байт включенной [Р-датаграммы. Хотя вы пометили байты как ООР-за- 
головок, это мог быть и заголовок ТСР: номера портов в обоих случаях находятся 
в одной и той же позиции. Формат ООР-заголовка показан на рис. 4.23. 


15 16 


Номер порта источника Номер порта назначения 
(иБ_вроге) (ип_арогЕ) 


Рис. 4.23. ЦОР-заголовок 


Текст функции рг1пе_пипгеаспа 1е приведен в листинге 4.6. 


Листинг 4.6. Функция риИпПЕ ипгеасваЫе 


1сптр.с 
1 зЕабё1с уо1за ре1пе_мпкеасваю1е( зекисЕе 1стр *1спр ) 
2 { 
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3 вЕгисЕ 1р *1ю; 

4 зЕгоасЕ парНаг *оар; 

5 сраг 1ааа[ 15 +1]; 

6 згаЕ1с сраг *ипгеасв[] = 
7 

8 


{ 


"Сеть недоступна", ОЙ 
9 "Хост недоступен", ЕН 
10 "Протокол недоступен", о 
11 "Порт недоступен", ие 
12 "Нужна фрагментация, поднят бит РЕ", /* 4 */ 
13 "Ошибка маршрутизации от источника", а 
14 "Сеть назначения неизвестна", /* 6 */ 
15 "Хост назначения неизвестен", 7 */ 
16 "Хост источника изолирован", м Вт 
17 "Сеть назначения закрыта администратором ", /* 9 */ 
18 "Хост назначения закрыт администратором ", /* 10 */ 
19 "Сеть недоступна для типа сервиса", /* 11 */ 
20 "Хост недоступен для типа сервиса", /* 12 */ 
21 "Связь запрещена администратором", /* 13 */ 
22 "Нарушение предшествования хостов", /* 14 */ 
23 "Действует отсечка предшествования" /* 15 */ 
24 }; 
2919. =: { ВЕЕмеЕ: 1р*.} 0 снав* Этеив + 89: 
26 цар = ( вЕкисЕ ичарьаг * )( ( сНак * )1р + ( 1р->1Р_11 <<2 ) ); 


27 зЕгсру( 1аЯах, 1пеё_пбоа( 1р->1р_вгс ) )}; 
28 рие1пЕЁЕ( "\Е%5\п\ЕИст.: %8.%а, Назн.: %$.%а\п", 


29 1спир->1спр_со@е < ( в12еоЁ( ипгеасН } / 
30 817еоЁ( ипгеасВ[ 0 ] ) )? 
З ипгеасв[ 1спир->1спр_соае ] : "Некорректный код", 


32 1ааахг, пеовз( пар->чб_врогй ), 
33 1пеё_пбоа( 1р->1р_ЯзЕ ), пЕорз( иар->чи_@арогё ) ); 
34} 
1спр.с 


Установка указателей иполучение адреса источника 


25-26 Начинаем с установки указателей 1р и чар соответственно на [Р-заго- 
ловок и первые восемь байт вложенной 1Р-датаграммы. 

27 Копируем адрес источника из [Р-заголовка в локальную переменную 
1ааак. 


Печать адресов, портов и типа сообщения 


28-33 Печатаем адреса и номера портов источника и назначения, а также 
уточненный тип сообщения о недоступности. 


В качестве примера использования программы 1СМР приведено несколько 
последних [СМР-сообщений, полученных при запуске Е гасегоцее (совет 35). 


Сгасегоцбе -а 1 пебсоп4 .пебсом. сом 


Опция -а 1 означает, что Е гасеходее должна посылать пробный запрос толь- 
ко один раз, а не три, как принято по умолчанию. 
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ТСМР Истекло время существования (11) от 11-0.щ14-Е1-9м1.1са.пеё 
(165.236.144.110) 

ТТЬ == 0 во время транзита 
ТСМР Истекло время существования (11) от $10-0-0.АРм-6х- 
9и1.1с9.пеЕ (165.236.32.74) 

ТТЬ == 0 во время транзита 
ТСМР Истекло время существования (11) от аАЁм-Ех-ам2.1са.пее 
Е бЗ. ТЕЗ) 

ТТЬ == 0 во время транзита 
ТСМР Пункт назначения недоступен (3) от пебсойи4 .пеёсом. сом 
(199.183.9.104) 

Порт недоступен 

Ист. 205.184.142.71.45935, Назн. 199.183.9.104.33441 


Обычно нет необходимости следить с помощью 1спр за работой сгасегоцке, 
но это может быть очень полезно для поиска причин отсутствия связи. 


Резюме 


В этом разделе разработан инструмент для перехвата и печати [СМР-сооб- 
щений. Такая программа помогает при диагностике ошибок сети и маршрути- 
зации. 

В ходе разработки программы 1стр использованы простые сокеты. Здесь вы 
познакомились с форматами [Р- и ОБР-датаграмм, а также со структурой 1СМР- 
сообщений. 


Совет 41. Читайте книги Стивенса 


В сетевых конференциях чаще всего задают вопрос: «Какие книги нужно чи- 
тать, чтобы освоить ТСР/1Р?». В подавляющем большинстве ответов упоминают- 
ся книги Ричарда Стивенса. 

В этой книге много ссылок на работы Стивенса. Для сетевых программистов 
этот автор написал две серии книг: «ТСР/Р Пиягаже4д» в трех томах и «ОМХ 
МекмогЕ Ргозгатииипя» в двух. Они преследуют разные цели, поэтому рассмотрим 
их по отдельности. 


«ТСР/Р Шизгаеа» 


Как следует из названия, серия «ТСР/[Р Шизгае4» трактует работу наибо- 
лее распространенных протоколов из семейства ТСР/ТР и программ, в которых 
они применяются. В совете 14 говорилось, что основное средство для исследова- 
ния — это программа Е сраитр. Запуская небольшие тестовые программы и наблю- 
дая за генерируемым ими сетевым трафиком, вы постепенно начинаете понимать, 
как на практике функционируют протоколы. 

Используя различные операционные системы, Стивенс показывает, что реа- 
лизации в них одного И того же протокола приводят к тонким отличиям в его ра- 
боте. Еще важнее, что вы учитесь ставить собственные эксперименты, а затем ин- 
терпретировать их результаты, отвечая тем самым на возникающие вопросы. 
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Поскольку в каждом томе семейство протоколов ТСР/Р рассматривается 
под разными углами зрения, имеет смысл кратко охарактеризовать каждую 
книгу. 


Том 1: Протоколы 

В этом томе описываются классические протоколы ТСР/ТР и их взаимосвязи. 
Сначала рассматриваются протоколы канального уровня, такие как Е{Вегпе*, 
УГ Р и РРР. Далее автор переходит к протоколам АВР и КАКР (Кеуегзе АЧ@гезз 
Везовиаюоп Ргоюсо] — протокол определения адреса по местоположению узла сети) 
и рассматривает их в качестве связующего звена между канальным и межсетевым 
уровнями. 

Несколько глав посвящено протоколу [Р и его связям с [СМР и маршрутиза- 
цией. Также анализируются утилиты ршё и игасегоще, работающие на уровне [Р. 

Далее речь идет о протоколе ОПР и смежных вопросах: широковещании и про- 
токоле [СМР Описываются также основанные на (ЮР протоколы: О№$, ТЕТР 
(Тима! ЕЦе Тгапзег Ргобосо] — тривиальный протокол передачи файлов) иВООТР 
(Вооёз гар Ргобосо] — протокол начальной загрузки по сети). 

Восемь глав посвящено протоколу ТСР. В нескольких главах обсуждаются 
распространенные приложения на базе ТСР, такие как {ештев, г|орт, ЕТР, ЗМТР 
(электронная почта) и МЕ$. 


Том 2: Реализация 

Второй том, написанный в соавторстве с Гэри Райтом (Сагу \/ 1180), - это прак- 
тически построчное описание сетевого кода из операционной системы 4.4В5О. По- 
скольку код из системы ВО широко признан как эталонная реализация, эта книга 
незаменима для тех, кто хочет лучше разбираться в реализации основных прото- 
колов семейства ТСР/ТР. 

В книге рассматривается реализация нескольких протоколов канального уровня 
(Еегпее, ЗЫР и возвратный интерфейс), протокола ГР, маршрутизации, прото- 
колов [СМР, [СМР ОПР и ТСР, группового вещания, уровня сокетов, а также не- 
сколько смежных тем. Поскольку автор приводит реальный код, читатель может 
получить представление о том, какие проблемы возникают при реализации слож- 
ной сетевой системы, и на какие компромиссы приходится идти. 


Том 3: ТСР для транзакций, НТТР, ММТР и протоколы в адресном домене ИМХ 

Третий том -— это продолжение первого и второго. Он начинается с описания 
протокола Т/ТСР и принципов его функционирования. Это описание построено 
так же, как и в первом томе. Далее приводится реализация Т/ТСР - по типу вто- 
рого тома. 

Во второй части рассматриваются два популярных прикладных протокола: 
НТТР (Нурекехе Тгапзег Рго{осо] - протокол передачи гипертекста) и ММТР 
(Мебмогк Ме\уз Тгапз{ег Ргофосо] — сетевой протокол передачи новостей), которые 
составляют основу сети \ойа УЛ4е \еБ и сетевых телеконференций Озепей со- 
ответственно. 
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И, наконец, исследуются сокеты в адресном домене ОМХ и их реализация. 
По сути, это продолжение второго тома, не включенное в него из-за ограничений 
на объем издания. 


«(МХ Мефлогк Ргодгатттд» 


В серии «СО МГХ МебхогК Ргоргатиип8» приведена трактовка ТСР/ТР для при- 
кладных программистов. Здесь рассматриваются не сами протоколы, а их приме- 
нение для построения сетевых приложений. 


Том 1. Сетевые АР!: Сокеты и ХИ 

Эта книга должна быть у каждого сетевого программиста. В ней очень подроб- 
но рассматривается программирование ТСР/ТР с помощью АР] сокетов и ХТ. 
Помимо традиционных тем, обсуждаемых в изданиях по программированию вар- 
хитектуре клиент-сервер, в данной книге затрагиваются групповое вещание, мар- 
шрутизирующие сокеты, неблокирующий ввод/вывод, протокол ГРуб и его рабо- 
ту совместно с ГРу4, простые сокеты, программирование на канальном уровне 
и сокета в адресном домене МХ. 

В этом томе есть особенно ценная глава, в которой сравниваются различные 
модели построения клиентов и серверов. В приложениях описываются виртуаль- 
ные сети и техника отладки. 


Том 2: Межпроцессное взаимодействие 

Во втором томе детально рассмотрены различные механизмы межпроцессного 
взаимодействия. Помимо таких традиционных средств, как каналы и Е ГЕО в ОМХ, 
очереди сообщений, семафоры и разделяемая память, впервые появившиеся в сис- 
теме 5узУ, обсуждаются и более современные методы межпроцессного взаимодей- 
ствия, предложенные в стандарте РОЗХ. 

Имеется прекрасное введение в изучение стандартизованных РОЗ[Х-потоков 
(Фгеа4з) и использования в них таких примитивов синхронизации, как мьютексы, 
условные переменные и блокировки чтения-записи. Для тех, кто интересуется ра- 
ботой системных механизмов, Стивенс приводит реализацию нескольких прими- 
тивов синхронизации и очередей сообщений в стандарте РОЗХ. 

Заканчивается книга главами об КРС (Кетое Ргосе4иге Са$ — вызовы уда- 
ленных процедур) и подсистеме $0]аг1$ Ооогз. 

Был запланирован и третий том, в котором предполагалось рассмотреть при- 
ложения, но, к несчастью, Стивенс скончался, не успев его завершить. Частично 
материал, который он хотел включить в третий том, можно найти в первом изда- 
нии книги «СДМХ МеёхогК Ргоргатитит8» [5еуепз 1990]. 


Совет 42. Читайте тексты программ 


Начинающие программисты часто спрашивают более опытных коллег, откуда 
тем столько всего известно. Конечно, знания и опыт приобретаются разными спо- 
собами, но один Из самых важных, хотя и недооцениваемых, — это чтение про- 
грамм, написанных мастерами. 
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Расширяющееся движение за открытые исходные тексты облегчает эту за- 
дачу. Чтение и разбор высококачественного кода имеют множество плюсов, са- 
мое очевидное — это ознакомление с подходом, выбранным экспертом для реше- 
ния задачи. Вы можете применить такую методику в своих программах, немного ее 
модифицировав и адаптировав. При этом вырабатываются собственные приемы. 
1И когда-нибудь будут читать уже ваш код и восхищаться красивым решеним. 

Не так очевидно, хотя в некоторых отношениях более важно осознание того, 
что нет никакой магии. Начинающие программисты иногда склонны думать, что 
код операционной системы или реализации протоколов непостижим, он создает- 
ся высшими силами, а простым смертным нечего и пытаться в нем разобраться. 
Но, читая код, вы понимаете, что это просто образец хорошей (по большей части, 
стандартной) практики инженерного проектирования, и вам это тоже под силу. 

Короче говоря, изучая код, вы приходите к выводу, что глубокое и таинствен- 
ное — в действительности вопрос применения стандартных приемов, овладеваете 
этими приемами и учитесь применять их на практике. Читать код нелегко. Для это- 
го требуется высокая концентрация внимания, но усилия окупаются сторицей. 

Есть несколько источников хорошего кода, но лучше получить еще и коммен- 
тарии. Книга Лионса «А Соштег(агу оп {Бе ОМХ Орегайпя8 Зузет» [4лоп$ 1977] 
давно уже ходила в списках. Недавно благодаря усилиям нескольких людей, в част- 
ности Денниса Ричи, и великодушию компании $СО, которая сейчас владеет ис- 
ходными текстами МХ, эта книга стала доступна широкой публике. 


Примечание Первоначально книгу могли приобрести только держатели ли- 
цензии на исходные тексты ИМХ, но подпольная ксерокопия 
(или копия с ксерокопии) была вожделенным призом для многих 
программистов в дни становления ОМХ. 


В книге приведен код очень ранней (шестой) версии операционной системы 
ОМУ, в которой не было сетевых компонент, кроме ТТУ-терминалов с разделени- 
ем времени. Тем не менее стоит изучить этот код, даже если вы не интересуетесь 
системой ОМХ, поскольку это прекрасный пример конструирования программ- 
ного обеспечения 

Еще одна отличная книга по операционным системам, включающая исходные 
тексты, — это «Орегайпя Зу%бетз: Оезеп апЯ Пиретегайоп» [ТапепБаит ап@ 
Уоо4Вий, 1997]. В ней описана операционная система МПМХ. Хотя в самом тек- 
сте сетевой код не приводится, но он есть на прилагаемом компакт-диске. 

Для тех, кого больше интересуют сетевые задачи, предназначен второй том 
книги «ГСР/ЛР Шизигаед» [У/иеВЕ ап Зеуепз 1995]. Она упоминалась в совете 41. 

Вэтой книге описывается код из системы В$О, на базе которой создано несколь- 
ко современных систем с открытыми исходными текстами (ЕгееВЗО, ОрепВ$О, 
Ме ВО). Она дает прекрасный материал для экспериментов с кодом. Оригиналь- 
ный код системы 4.4В5Р [Ще можно получить с ЕТР-сервера компании У/ашие 


Стеек СО-КОМ (Ёр://Ёр.сагот.сот/рцЬ/4.4В$О-Ге). 
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Во втором томе книги «Работа в сетях: ТСР/ТР» [Сотшег ап4 З$(еуепз 1999] 
описан другой стек ТСР/ТР. Как и в предыдущей, в ней приводится подробное 
объяснение принципа работы кода. Код можно загрузить из сети. 

Есть много и других источников кода, хотя, как правило, он не сопровождается 
пояснениями в виде книги. Начать можно с открытых систем ОШХ или Ипах. Для 
всех подобных проектов исходные тексты доступны на СО-КОМ или через ЕТР. 

В проекте СМО, основанном фондом Егее Зой\аге Еоипдайоп, имеется исход- 
ный текст переписанных с нуля реализаций большинства стандартных утилит 
ОМХ. Это тоже отличный материал для изучения. 

Информацию об этих проектах можно найти на следующих сайтах: 


о домашняя страница ЕгееВ$О ЬИр://м\мтееБза,огв; 


О проект СМО Вер: //м\\ пи. ге; 
О архивы ядер Шпих Вбр: //мжмжКегпе|.ог; 


О домашняя страница №её ВЗР  Вир://мжмпе$4.огв; 
о домашняя страница ОреП ВЗР Бр://\ужуи\.орепЬз.огв. 


В каждом из этих источников есть огромное количество исходных текстов, свя- 
занных с сетевым программированием, и их стоит изучить, даже если ОМХ не 
находится в сфере ваших интересов. 


Резюме 


Один из лучших способов изучения сетевого программирования (да и любого 
другого) — это чтение программ, написанных людьми, уже достигшими вершин 
мастерства. До недавнего времени было нелегко получить доступ к исходным 
текстам операционных систем и их сетевых подсистем. Но в связи с распрост- 
ранением движения за открытость исходных текстов ситуация изменилась. Код 
нескольких реализаций стека ТСР/Р и соответствующих утилит ({етеё, ЕТР, 
шей ит.д.) доступен для проектов ЕгееВЗР и Ипих. Здесь приведены лишь неко- 
торые источники, в Ц{егпеё можно найти множество других. 

Особенно полезны книги, в котрых есть не только код, но и подробные ком- 
ментарии к нему. 


Совет 43. Изучайте ВЕС 


Ранее говорилось, что спецификации семейства протоколов ТСР/ТР и связан- 
ные с ними архитектурные вопросы [тцегпей содержатся в серии документов, объе- 
диненных названием Ведиезе юг Соттепз (ВЕС — Предложения для обсужде- 
ния). На самом деле, ВЕС, впервые появившиеся в 1969 году, — это не только 
спецификации протоколов. Их можно назвать рабочими документами, в которых 
обсуждаются разнообразные аспекты компьютерных коммуникаций и сетей. Не 
все КЕС чисто технические, в них встречаются забавные наблюдения, пародии, 
стихи и просто различные высказывания. К концу 1999 года было более 2000 при- 
своенных ВЕС номеров, правда, некоторые из них так и не были опубликованы. 
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Хотя не в каждом ВЕС содержится какой-либо стандарт Пуегпеф, любой стан- 
дарт Пиегпей опубликован в виде КЕС. Материалам, входящим в подсерию КЕС, 
дается дополнительная метка «5ТОхххх». Текущий список стандартов и тех ВЕС, 
которые находятся на пути принятия в качестве стандарта, опубликован в доку- 
менте 5ТО0001. 

Не следует, однако, думать, что КЕС, не упомянутые в документе 5ТРО001, 
лишены технической ценности. В некоторых описываются идеи пока еще разра- 
батываемых протоколов или направления исследовательских работ. Другие содер- 
жат информацию или отчеты о деятельности многочисленных рабочих групп, со- 
зданных по решению ТЕТЕ (Пиегпеё Епетеения ТазК Еогсе — проблемная группа 
проектирования Пиегией). 


Тексты ВЕС 


Получить копии КЕС можно разными путями, но самый простой — зайти на 
У'еБ-страницу редактора ВЕС Бр://Лумиу-едЦог.огя. На этой странице есть 
основанное на заполнении форм средство загрузки, значительно упрощающее по- 
иск. Есть также поиск по ключевым словам, позволяющий найти нужные ВЕС, 
если их номер неизвестен. Там же можно получить документы из подсерий ЭТО, 
БУГ и ВСР (Везё Сиггепе Ргасисез — лучшие современные решения). 

ВЕС можно также переписать по ЕТР с сайта Креди из каталога ш-пофез/ 
и из других ЕТР-архивов. 

Если у вас нет доступа по протоколам НТТР или ЕТР то можно заказать ко- 
пии ВЕС по электронной почте. Подробные инструкции о том, как сделать заказ, 
а также список ЕТР-сайтов вы получите, послав электронное сообщение по адре- 
су гк-шю@1Я.еди, включив одну строку: 


Ве1р: пауз_бо_деб_тгЁсз 


Какой бы способ вы ни выбрали, прежде всего надо загрузить текущий указа- 
тель КЕС (файл гЕс-1пдех.ЕхЕ). После публикации ни номер, ни текст ВЕС уже 
не изменяются, так что единственный способ модифицировать КЕС - это выпус- 
тить другое КЕС, заменяющее предыдущее. Для каждого КЕС в указателе отмече- 
но, есть ли для него заменяющее ВЕС и если есть, то его номер. Там же указаны 
ВЕС, которые обновляют, но не замещают прежние. 

И, наконец, различные компании поставляют КРС на СО. Так, \Машице СгееК 
СР-КОМ (Биф://ммсагот.сот) и шЮМаяс (Бр:/ мужи иютарс.сот) предла- 
гают компакт-диски, на которых записаны как ВЕС, так и другие документы, от- 
носящиеся к Пицегле. Разумеется, перечень КЕС на таких дисках быстро стано- 
вится неполным, но, поскольку КЕС сами по себе не подлежат изменению, диск 
может устареть только в том смысле, что не содержит последних ВЕС. 


Совет 44. Участвуйте в конференциях Ц5епе 


Одно из самых ценных мест в Пуегпе{ в плане получения советов и инфор- 
мации -— это конференции Озепеф, посвященные сетевому программированию. 


Конференции Цбепе" и! | |301 


Существуют конференции практически по любому аспекту сетевых технологий 
от прокладки кабелей (сотр.4сот.саБ пя) до синхронизирующего сетевого прото- 
кола МТР (сотр.ргофосо!.Ителфр). 

Замечательная конференция, относящаяся к протоколам семейства ТСР/Р 
и программированию с их помощью, — сотр.ргоёосо!34ср-1р. Всего лишь несколько 
минут, ежедневно потраченных на просмотр сообщений в этой конференции, даст 
массу полезной информации, советов и приемов. Обсуждаемые темы варьируют- 
ся от подключения к сети машины под управлением УЙп4о\/з до тонких техни- 
ческих вопросов по протоколам ТСР/ТР, их реализации и работы. 

В самом начале знакомства с конференциями по сетям вызвать недоумение 
может даже простое их перечисление (а их не меньше 70). Лучше всего начать 
с конференции сотр.ргобосо! (р-р и, возможно, одной из конференций по конк- 
ретной операционной системе, например, сотр.оз.Нпих.пебмогкше или сотр.тз- 
у\лп4о\.рговгаттег. {001 \1зоск. Сообщения в этих конференциях могут содер- 
жать ссылки на другие, более специальные конференции, которые тоже могут 
быть вам интересны или полезны. 

Один из лучших способов чему-то научиться в сетевых конференциях - это 
отвечать на вопросы. Изложив свои знания по конкретному вопросу в форме, по- 
нятной для других, вы сами глубже разберетесь в проблеме. Небольшое усилие, 
требуемое для составления ответа из 50-100 слов, окупится многократно. 

Отличное введение в систему конференций Озепе находится на сайте Инфор- 
мационного центра Озепеё (В&р://теааБ. ипс.еди/изепе-1/). На этом сайте есть 
статьи по истории и использованию Озепек, а также краткая статистика для боль- 
щинства конференций, в том числе среднее число сообщений в день, среднее чис- 
ло читателей, адрес модератора (если таковой есть), где хранится архив (если он 
ведется) и ссылки на часто задаваемые вопросы (ЕАО) для каждой конференции. 

На сайте Информационного центра Озепе{ есть поисковая система, позволяю- 
щая найти конференции, в которых обсуждается интересующая вас тема. 

Выше упоминалось, что во многих конференциях ведутся ЕАО, с которыми 
стоит ознакомиться, прежде чем задавать вопрос. Если задать вопрос, на который 
уже есть ответ в ЕАО, то, скорее всего, вас к нему и отощлют, а, может быть, и по- 
журят за нежелание потрудиться самому. 


Другие ресурсы, относящиеся к конференциям 


Следует упомянуть еще о двух ценных ресурсах, связанных с сетевыми кон- 
ференциями. Первый - это сайт Ое]аМемз (ВЫр:/ ух. Аеа.сот). 


Примечание В мае 1999 сайт Оеа №5 изменил свое название на Дега.сот. 
Владельцы объясняют это расширением спектра услуг. В этом 
разделе говорится только о первоначальных услугах по архива- 
ции сообщений из сетевых конференций и поиску в архивах. 


На этом сайте хранятся архивы примерно 45000 дискуссионных форумов, 
включая конференции Озепеё и собственные конференции Оеа Соттирйу 
015сиз1опз. Владельцы Оеда.сот утверждают, что примерно две трети всех архивов 
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составляют сообщения из конференций Озепе*. На конец 1999 года в архивах хра- 
нились сообщения, начиная с марта 1995 года. 

Поисковая система сайта Ро\ег ЗеагсВ позволяет искать ответ на конкретный 
вопрос или информацию по некоторой проблеме в отдельной конференции, в груп- 
пе или даже во всех конференциях по ключевому слову, теме, автору или диапазону 
дат. Второй ценный ресурс — это список ресурсов по ТСР/ТР (ТСР/ТР Везоигсез 
1150) Юри Раца (Оп! Ка2), который каждые две недели рассылается в конферен- 
цию сотр.рговосо]$4ср-1р и некоторые более специальные. Этот список - отличная 
отправная точка для тех, кто ищет конкретную информацию или общий обзор 
ТСР/ТР и соответствующих АР]. 

В списке имеются ссылки на книги по этому вопросу и другим, касающимся 
сетей; онлайновые ресурсы (к примеру, страницы ТЕТЕ и сайты, где размещаются 
КАО); онлайновые книги и журналы, учебники по ТСР/ПР; источники информа- 
ции по протоколу 1Руб; домашние страницы многих популярных книг по сетям; 
домашние страницы книжных издательств; домашние страницы проекта СМО 
и открытых операционных систем; поисковые машины с описанием способов ра- 
боты с ними и конференции, посвященные сетям. 

Самая последняя редакция списка находится на сайтах: 


а БЕ: //млуумуриуа*е. оге1| ср з 
а ВЕ: /ЛуимлиБезесот,.Ц/= е 1 се 


Также информация может быть загружена по ЕТР с сайтов: 


с Ёр: 1.е4 зепе!-Бу- апз\ег$ /1 {Еср-! зопгсе- 
[56 
с Ёр: //тёбо, м еди/раб /изепе{-Бу-Шегагс г0+0с0|$ /4ср-12/ТСР- 


ГР_КВезоигсез_[.1$. 


Особую ценность списку ресурсов по ТСР/ТР придает тот факт, что автор ре- 
гулярно обновляет его. Это немаловажно, так как ссылки в \\№еЬ имеют тенденцию 
быстро устаревать. 


Приложение 1 


Вспомогательный код для УМХ 


Заголовочный файл еср.П 


Почти все программы в этой книге начинаются с заголовочного файла её ср.п 
(листинг П1.1). Он подключает и другие необходимые файлы, в том числе зКе!1 .п 
(листинг П2.1), а также определения некоторых констант, типов данных и прото- 
ТИПОВ. 


Листинг ПТ. Т. Заголовочный файл екр.п 


еёср.р 
#1Епа4еЕ __ЕТСР_Н__ 
#аеЁ1пе __ЕТСР_Н__ 


/* Включаем стандартные заголовки. */ 


#1ис1аае <егхгпо.Н> 
#1ипс1аае <з6а11Ь.НВ> 
#1пс1а4е <ип1зёа.Н> 
#1ипс1иае <з691о.1> 
#1ис1а4е <зЕЯагд.П> 
#1ипс1ае <зег1па.Н> 
#1пс1аае <песаь.Н> 
#10с1а4е <5з19па1.1> 
#1пс1ае <ЁспЕ1.В> 
#1пс1ае <зуз/воскее.и> 
#1пс1ае <зуз/ма1е.Н> 
#1пс1а4е <зуз/Е1ще. > 
#1пс1аае <зуз/гезоцксе.Н> 
#1пс1а4е <зуз/збае.В> 


на на на на на на на на 
эмм оюноюочяаячр о юьв 


18 #1пс1аае <плеб1тее/ шт. в> 

19 #1пс1аае <агра/зпее.и> 

20 #1пс1аае "зКе1.в" 

21 #аеЕ1пе ТВОЕ 1 

22 #аеЁ1те БРАЬЗЕ 0 

23 #аеЁ1пе МТ$ТЕМ 5 /* Максимальное число ожидающих соединений. */ 
24 #+аеЕ1пе ММВ 5 /* Число буферов в разделяемой памяти. */ 
25 #аеЕ1пе $МВОЕ52256/* Размер буфера в разделяемой памяти. */ 
26 ехсегпг сваг *ргодгам_паще; /* Для сообщений об ошибках. */ 
27 #1ЕаеЕ __$УВ4 
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28 #ЧеЕ1те Ъхего(Ь,п) пензе ( (Ь), 0, (тп) } 
29 #епа1Е 
30 Еуре@аеЕ уо1@а ( *БоЕРипс_Е )( уола * }; 


31 \о1& ехггког( 1пЕ, 116, сБаг*, ... ); 
32 116 геаЯп( СОСКЕТ, сБахг *, $17е_ ); 
33 116 теа@угес( ЗОСКЕТ, сваг *, $17е ) 
34 1пЕ геааск1Е( ЗОСКЕТ, свах *, 517е_® ); 
35 1пЕ геаЯ11пе( СОСКЕТ, сраг *, з12е_ ) 
36 1пЕ Еср_зекуек( саг *, сраг * )}; 
37 1аЕ Еср_с11епе( сБахк * 
38 11Е иар_зекуек( саг *, сраг * ); 
39 1пЕ цар_с11епё( сВаг *, срак *, зЕегкиасе зоскааак_1п * ); 
40 1пЕ Езе1есе( 116, Еа_зеёе *, Е@а_зе® *, Еа_веё *); 
41 ипз1апеяа 106 Е1меоце( вбоЕипс_©, уо1а *, 1щЕ ); 
42 уо1а ипЕе1меоче( ипз1апеа 1106 ); 
43 \хо1а 1п16_эиЪ( 106 ); 
44 уо1а *этра11о0ос( \о1а }; 
45 \01Я эпЬЕгее( уо1а * ); 
46 01а эпьзепЯ( 5ОСкКЕТ, чо1а * )}; 
47 уо18 *зигесу( $ОСКЕТ ); 
48 \о1Я зеб_а@агез5( сраг *, сраг *, зегасе зоскааахг 1п *, саг * ); 
49 #епа1Е /* __ЕТСР_Н__ */ 

еЁср.В 


Функция даетоп 


Функция Яаетоп, которая использована в программе Есртих, входит в стан- 
дартную библиотеку, поставляемую с системой В5О. Для систем ЗУ КА приводит- 
ся версия, текст которой показан в листинге 11.2. 


Листинг П1.2. Функция даетоп 


даетоп.с 

1 1пЕ Заемоп( 116 пос@а, 1пе пос1озе } 

а 

3 $ЕкисЕ х11116 :110; 

4 рае рта 

5 216 1; 

6 умазк( о); /* Очистить маску создания файлов. */ 

7 /* Получить максимальное число открытых файлов. */ 

8 1Е ( деЕх11щ1е( ВЫТМТТ МОЕТЬЕ, &х11п ) < 0) 

р еггохг( 1, егхпо, "дебг11т1е Еа11еа" )}; 

10 /* Стать лидером сессии, потеряв при этом управляющий терминал... */ 

11 р1а = ЕогКк(); 

12 Е ра < :02 

13 гебигп -1; 

14 ТЕ ра 1= 0) 

15 ех1® (0); 
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16 
17 


18 
ТЯ 
20 
21 
22 
23 


24 


25 
26 


27 
28 
29 
30 
31 


38 
33 


зеёз1а(); 
/*... И гарантировать, что больше его не будет. */ 


з1апа1( $УТСНОР, $1С_ТСМ ); 
р1а = ЕокКкК(); 
Е) 

гебигпт -1; 
1Е (ра != 0) 

ех1Е (0); 


/* Сделать текущим корневой каталог, если не требовалось обратное */ 


1Е ( !поса ) 
СВОЕ "7" 
/* 
* Если нас не просили этого не делать, закрыть все файлы. 
* Затем перенаправить зЕ41п, зЕЯоцЕ и зЕаегк 
* на /аеу/го11. 
ый 


1Е ( !пос1ове ) 


{ 


34 #1Е 0 /* Заменить на 1 для закрытия всех файлов. */ 


35 1Е (:11м.:11п_мах == ВЬЫТМ_ТМЕТМТТУ ) 
36 х110.:11щм_мах = 1024; 

37 Бог (1=0; 1 < у11]м.кЪ а мах; 1++ ) 
38 с1озе( 1}; 

39 #епа1Е 

40 1 = ореп( "/аеу/по11", О_ВРМВ ); 

41 Е (1< 0) 

42 гебихуп -1; 

43 аир2 (1, 0); 

44 авт, 1) 

45 За 

46 Ета 

47 с1о5е( 1); 

48 } 


49 гебатп 0; 


50 } 


Ум ааето.с 


Функция $дпа! 

В этой книге уже упоминалось, что в некоторых версиях ОМПХ функция $10пта1 
реализована на основе семантики ненадежных сигналов. В таком случае для полу- 
чения семантики надежных сигналов следует использовать функцию з1часе1оп. 
Чтобы повысить переносимость, необходимо реализовать 319па1 с помощью 
з1часЕ1оп (листинг П1.3) 
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Листинг П1.3. Функция 51дпа! 


519па1.с 
/* з319па1 - надежная версия для $5УВ4 и некоторых других систем. */ 
1 суреаеЕЁ уо1а зларпа1к_&( 116 ); 
2 эларпа1к_Е *$1д9па1( 1106 $149, з1арпа1к_Е *ВиЯ1х ) 
3 { 

зЕкисЕ з1дасЕ1оп асЕ; 

зЕкисЕ 51дасё1оп хас®; 


асе.за_Е]адаз = 0; 


4 

5 

6 асе.за_ВапЯ1ег = Впа1к; 

7 

8 51депрфеузеф ( &асе.за_мазКк }; 


9 1Е ( эз1дасе1оп( $149, &асе, &хас®е ) < 0} 
10 гебагп 51С_ЕВК; 

11 гебоагп хасе.за_Вап@1ег; 

12 } 


519па1.с 


Приложение 2 


Вспомогательный код для \МЛпдо\и$ 


Заголовочный файл 5Ке!. В 


Для компиляции примеров программ на платформе УЛп4о\з вы можете 
пользоваться тем же файлом е&ср .П, что и для ОМХ (листинг П1.1). Вся систем- 
но зависимая информация находится в заголовочном файле зке!1 .|, версия кото- 
рого для \УЛп4о\з приведена в листинге 2.1. 


Листинг П2.1. Версия $Ке!.П для ИЛпао\/$ 


+ + 
нофхфочам пр ф ън 


Е > 
ом 


НН 3 
ом г 


шмфьюмюьввв 
шо юон-ч 


5%) 
> 


#1ЕпаеЕЁ __$УКЕЦ_Н__ 
#ЧеЕ1пе __ $УКЕГШ_Н__ 


/* Версия М1пзоск. 


#1пс1аае <и1п9омз.Н> 
#1пс1аае <и1пзоск2.Н> 


зехасЕ Е1мехопе 


#АеЕ1пе 
#АеЕ1пе 
#АеЕ1пе 


#АеЕ1пе 


#аАеЕ1пе 
#АеЕ1пе 
#+аАеЕ1пе 
#АеЕ1пе 
#ЧеЕ1пе 
#ЧеЕ1пе 


#епа1Е 


Е>_п]пибезмезе; 
$7_ЯзЕЕ1ме; 


ипз1апея зп ц_11632_Е; 


ЕМЗСЫТОЕ 
ТТТ) 
ЕХТТ (3) 
СЪОЗЕ (3) 


еггпо 


зеб_еггпо (е} 
15уа11Я5осК (3) 
Бтего (,п) 


31еер (6) 
ИТМО $ 


/* __ КЕШ Н___ */ 


ИУЗАЕМЯСЯТЕЕ 
1116( акау ); 


Яо { МЗАС1еапор(); 


м111е (0) 


1Е ( с1озезоскКеё( $ ) 


еггог (1, 


еггпо, 


( СебтазЕЕхкгог() ) 


бесргазеЕггоек ( 
( (3) 
О «И 
31еер( (6) 


(е ) } 


п )) 
* 1000 ) 


Функции совместимости с МИпЧо\!$ 


В листинге П2.2 приведены различные функции, которые использованы 
в примерах, но отсутствуют в УЛи4до\. 


ех1 ( 


) 


\ 


!1= ЗОСКЕТ_ЕВВОВ ) 


( 


5 


) 


); 


эке!1.п 


Ри 


"ошибка вызова с1озе") 


зке1.БЬ 
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Листинг П2.2. Функции совместимости с ИЙпдои/$ 


и1псопрае.с 
1 Нипс1аае <вуз/&1теь.|> 

2 #1пс1иае "еёср.В" 

3 #1пс1а4е <и1пзоск2.1> 


4 #4еЕ]пе МТМВУОЗОСКЕВЕВ { УЗАЕМОЧЬОВЬОСК ) 

5 #АеРзпе МАХВУОСОСКЕВЕ { МТМВООЗОСКЕВК + \ 

6 ( 312еоЁ( Бз@азоскевегг8 ) / \ 

7 $12е0оЁ( ЬзЧвосКкКебегг[ 0] )) } 


8 ехбехп 1пЕ вуз_пегг; 

9 ехбегп снах *5у5_етг1156[]; 
10 ехЕехгп сВахг *рходгап_паме; 
11 эзбае1с сВаг *Бздзоскебегг$[] = 


12 { 

13 "Везоцксе бетрогаг1]1у ипауа1]аБ1е", /* Ресурс временно недоступен. */ 
14 "Орегае1оп пом 1п ргодгезз", /* Операция начала выполняться. */ 
15 "Орекаё1оп а1хеаду 1п ргодгезз", /* Операция уже выполняется. */ 

16 "босКкеЕ орегаё1оп оп поп-восКкее", /* Операция сокета не над сокетом. */ 
17 "Бевзе1пае1оп аЧагезз геда1те@Я", /* Нужен адрес назначения. */ 

18 "Меззаде боо 1опа", /* Слишком длинное сообщение. */ 

19 "Ргобосо1 мкопа буре Ёог зосКеЁ", /* Неверный тип протокола для сокета. */ 
20 "Ва@ рхобосо] орЕ1оп", /* Некорректная опция протокола. */ 
21 "Ркобосо] поё виррогёеа", /* Протокол не поддерживается. */ 
22 "боскеё буре поЕ виррогее@", /* Тип сокета не поддерживается. */ 
23 "ОрегаЕ1оп поЁ зиррогёе@", /* Операция не поддерживается. */ 
24 "Ргобосо]1 Ёаш1]у поЕ зиррогее@", /* Семейство протоколов не */ 


/* поддерживается. */ 
25 "Аадхезз Гаш1]у поЕ зиррогееЯ Бу ргобосо] Ёат11у", /* Адресное семейство */ 
/* не поддерживается семейством протоколов*/ 


26 "Аабхезз а]1хеаду 1п цве", /* Адрес уже используется. */ 

27 "Сап'Е азз1ап геацезееЯ а@дхезз", /* Не могу выделить затребованный */ 
/* адрес. */ 

28 "МебмохКк 1$ ао", /* Сеть не работает. */ 

29 "МебмогКк 13 чпгеасра Ре", /* Сеть недоступна. */ 


30 "МеЕмохК ЯгорреЯ соппесЕ\1оп оп хезее", /* Сеть сбросила соединение */ 
/* при перезагрузке. */ 
31 "боЁЕбмаге сацзей соппесе1оп аБогё", /* Программный разрыв соединения. */ 


32 "СорпесЕ1оп гезеЕ Бу рее!", /* Соединение сброшено другой */ 
/* стороной. */ 

33 "Мо БаЕЕег зрасе ауа11ае", /* Нет буферов. */ 

34 "босКкее 15 а1геа@у соппесееа", /* Сокет уже соединен. */ 

35 "босКкее 15 поЁ соппесееа", /* Сокет не соединен. */ 


36 "СаппоЕ зеп@ аЁфех зоскеё зПаЕдожт", /* Не могу послать данные после */ 
/* размыкания. */ 

37 "Тоо папу хеЁегепсез: сап’@ зр11се", /* Слишком много ссылок. */ 

38 "Соппесе1от Е1\меЯ оцё", /* Таймаут на соединении. */ 

39 "Соппесе1оп геЁазеа", /* В соединении отказано. */ 

40 "Тоо шару 1еуе1$ оЁ зупро11с 11пКк5", /* Слишком много уровней */ 
/* символических ссылок. */ 


41 "Е1]е паше воо 1опа", /* Слишком длинное имя файла. */ 
42 "НозЕ 15 Зомп", /* Хост не работает. */ 

43 "Мо гоцЕе во Возе" /* Нет маршрута к хосту. */ 

44 }; 


45 уо1Я 101%( сНак **агах ) 
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46 { 

47 ИЗАРАТА мзадаса; 

48 ( рхоагат_паше = зеггсрке( акоу[ 0 }, '\\' )} } ? 
49 ргоагат_пате++ : ( ргоадгам_паше = агду[ 0] )}; 
50 ИЗАЗЕакЕир( МАКЕМОКО( 2, 2 }, &мзадаса )}; 

51 } 


52 /* 1пеё_абоп - версия 1пеЕ_абоп для 5Уг4 и \1паомз. */ 
53 116 1пеё_абоп( сВак *ср, зЕгасе 1п_а@ак *р1т ) 


54 { 

55 106 гс; 

56 гс = 1пеб_ааЯг( ср ); 

57 1ЁЕ (гс == -1 && эегстр( ср, "255.255.255.255" ) ) 
58 гебаги 0; 

59 р1п->5_а@акг = гс; 

60 гебагп 1; 

61 } 


62 /* десе1теоЁдау - для Езе1есе. */ 
63 1пЕ деее1теоЕЧау( зегасЕ Е1теуа1 *ЕуУр, зЕгасЕ Е егопе *ётр } 


64 { 

65 зЕГаСЕ 6 1мер 65; 

66 _ЕЕ1ще( &6 ); 

67 1Е (СР ) 

68 { 

69 Сур->ЕУ_зес = {Ъ.61те; 

70 вур->6У_ изес = {6.111116 * 1000; 
71 } 

72 1Е ( Етр ) 

73 { 

74 67р->62_папибезмезе = ЕЪ.Е1щегопе; 
75 62р->62_азЕ Еще = ЕР.а5ЕЕ1ад; 

76 } 

1: 


78 /* зекеггог - версия, включающая коды ошибок \1пзосКк. */ 
79 спах *зегегхког( 106 ехг ) 


80 { 
81 1Е ( ехг >= 0 && егг < вуз_пегг )} 
82 хегигп зуз_егхг1156[ ехг ]; 
83 е15е 1Ё ( егхг >= М1МВЗОЗОСКЕВВ && егг < МАХВЗОЗОСКЕВВ ) 
84 гееагп БэдвосКкекегуз[ егг - МТМВООбОСКЕВК }]; 
85 е1зе 1Ё ( ехх == МСАСУЗМОТВЕАОУ ) 
86 гебигп "Мебмогк забзузеем 1$ ппиза1е"; 
/* Сбетевая подсистема неработоспособна. */ 
87 е1зе 1ЁЕ ( егх == ИСАУЕВМОТ$ОРРОВТЕР ) 
88 гебитп "ТЬ15 уегз1оп оЁ ИМ1пзосКк поЁ зиррогёеа”; 
/* Эта версия У1пзоск не поддерживается. */ 
89 е1зе 1Ё ( ехх == УСАМОТТМТТТАЬТЬЗЕО ) 
90 гебаги "\пзосКк поё 11161а117е@"; 
/* \1пзосКк не инициализирована. */ 
91 е1 зе 
92 тегахи "ОпКпомп еггог"; 
/* Неизвестная ошибка. */ 
93 } 
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